#76 master and slave repositories

Opened by gabomgp, on May 9, 2017
gabomgp commented on May 9, 2017


I think i understand the wish to get maximum flexibility in pijul repositories. For exemple with the unespecified order of the patches. But, for simplicity and familiarity, what if:

  • Any repository can be master repository or slave repository.
  • A master repository is one whose patches are stably ordered. That is, when a patch is recorded, its position in the story will never change. When new patches arrive to the repository by pull or push, the new patches are sorted after all previously existing ones in the repository. The purpose of this is to be able to deduce the set of patches that should be applied when you ask about the state of the files at a given date or position. So, if for example I compile my project from the sources that are in pijul, I can show the user a date and with that date anyone can recover from the master repository the exact same versions of the sources that were used to compile.
  • A slave repository is one whose patches are provisionally ordered, and when pulling or pushing with a master repository, it is the order of the master repository that must remain in the slave repository. So only if I have not introduced new patches in the slave repository (from last pull/push/clone), I can be sure that the order of my patches is the same as the official one.
  • In a master repository it is forbidden to alter the previous history, so you could not unrecord previous patches. You lose flexibility to gain simplicity to refer to a set of patches in the history.
  • Maybe, we need stability in the history of patches inside a branch in the repo and not inside the whole repository.
gabomgp commented on May 9, 2017

Or maybe instead of master and slave repositories, we can have:

  • branches with stable histories, a la master repository.
  • branches with unestable histories, a la the branches of today, with maximum flexibility.
  • branches with slave histories, a la slaves repositories.
joeneeman commented on May 9, 2017

I was also thinking along these lines, with something like "git bisect" in mind. One issue with the "set of patches" view is that there might be semantic dependencies among patches that pijul doesn't know about because they aren't textual dependencies (e.g. introduce a new function in some file, and then later use it in a different file). The consequence is that arbitrary sets of patches might not be buildable, which would make a "bisect" command hard.

But here's a slightly different idea for solving it: we keep branches as they are and add a new thing called a "history", which is just a sequence of sets of patches. Day-to-day work would be on branches, and the history would be mainly for archival purposes and bisecting.

gabomgp commented on May 9, 2017

Maybe, we can have metadata in the patches for the "no textual" dependencies. In other issue i saw mention to that posible metadata. So, when i use a date or position (a la TFS, patch number 443, to say something), all the patches applied before that date or position (including hard dependencies and metadata dependencies) are used. I suppose a patch can't depend on other patch that is not previusly in the stable history. Using positions is convenient for bisecting, more simple user interacion, i think.

joeneeman commented on May 10, 2017

I'm skeptical that we could detect non-textual dependencies automatically, since they depend on the semantics of the code in version control.

gabomgp commented on May 10, 2017

I don't think the metadata for non textual dependencies can be automatic. But that metadata impose a order in the patches of the history. When i bisect a history (or a branch with stable history), the patches are strictly ordered with dependants after dependencies.

pmeunier commented on May 19, 2017

Sorry for being so late to answer to such an important question.

First of all, there is no "official order" in Pijul. A branch is a set of patches, and all possible orders yield the exact same repository.

Now, I also understand the need to refer to a specific position. The issue is, your coauthors may not have all the patchsets you've had in your history. Example with Alice and Bob working together:

  • Alice and Bob start with the same patchset containing a single patch /I/.
  • Alice produces a patch /A/, Bob a patch /B/.
  • If Alice wants to tell Bob to look at version {/I/, /A/}, "'cause that's the one that worked", she has no choice but to send him the patchset.

One way to send patches with the current version of Pijul is to create a branch (because a branch is a patchset) in a shared location, such as the Nest. Another way could be to add a way in the CLI to create "tag patches". The patch format already allows this.