pijul_org / pijul

#88 Create a branch per release

Opened by lthms, on May 12, 2017
Closed
lthms commented on May 12, 2017

Currently, we have no way to know which patches are belonging to which releases. One thing that can be done (I actually am doing it for the software I release and host in the nest, such as lkn-prelude is to create a branch per release and leaves it untouched one published. A way to lock a branch (a tag in pijul has the semantics of a locked branch, imo) would be a perfect add to the Nest, but that’s not the point here.

hard_lines commented on May 12, 2017

Adding a branch per release may just clog up the presentation of the branches in the repository, especially if you make many small releases. Darcs understands tags to be a special kind of patch, one which simply defines a fixed set of patches, and typically is intended to represent a milestone reached, or a release: "By default a tag names the entire repository state at the time the tag is created." Thus, a tag includes amongst its dependencies all patches theretofore applied to the repository. I believe that you can list only the tags on a Darcs repo (but i cannot remember the command). Perhaps the semantics you suggest would be appropriate, but locked branches (i.e. tagged states of the repo + releases) should be separately presented to the user, i.e. not listed by the command pijul branches, and instead be listed by a seperate command e.g. pijul tags or pijul releases.

The downside of this kind of approach (i.e. understanding tags/releases as locked branches rather than a special kind of patches), is that it wouldn't afford the system any understanding of later patches (or tags) depending on a tag or release (i.e. depending on all of the patches defined by the tag/release conjointly), it would only afford the system an understanding of the dependencies later patches have on the subset of patches within the tag (understood as a locked branch) that the system already knows that such later patches depend on.

This problem may not concern one, especially if one is particularly attached to the perspective of a repo simply being a set of partially ordered patches. However, there are obvious reasons for wanting to understand a repo as a confluent tree recording a history of changes, in particular it sits much more naturally with bug tracking, where ideally we would like to associate a particular issue with a global states of a repo at a particular point in its history. Adding monolithic tags could be a better way to represent the historical dependencies of bugs than using locked branches.

These are just some rough thoughts.

pmeunier commented on May 12, 2017

This is indeed an interesting discussion. Both have downsides and upsides:

  • Branches share only the disk space the have in common with other branches, i.e. not much after enough time, but are immediately accessible.

  • The darcs way is less wasteful, but all the patchs since the tag might take time to unrecord (linear in the size of history).

For the Pijul source code itself, I agree we should start doing something like this. I'm a bit nervous about doing before fixing other issues we are having with conflicts.

lthms commented on May 12, 2017

I am not sure if this remarks meets hard_lines feedback, but if a tag in pijul is implemented as a locked branch internally, a very important tool to add is a way to compare two branches. I am not sure such command is already present in the current version.

lthms commented on June 5, 2017

This will be discuss in discourse rather than here, along with other workflow related stuff.