Pijul

Any plans to make tags first-class things?

#1

I’m a professional developer. I think in terms of delivering software and maintaining it.

From that perspective, Pijul is a non-starter for me, because when I look at the repo and see just a long tower of patches (which can be reshuffled at every moment), I become very confused and scared. If I have deployed that project yesterday, does the deployed code look anything like I see in the repository now?

One of the most valuable features of GitHub is to see the code at a certain version. Or, when looking at a commit, to see which versions was it included in. Neither feature is available in Pijul. Branches are not the same thing, they are not fixed in stone.

The reason that “patch chain” model did not yet win over the “snapshot” model is because there is a lot of value in thinking of the code in terms of frozen snapshots. Being able to reshuffle and merge the changes during the development is nice, but: the code needs to be released, reviewed, audited. And all that is best done with snapshots.

So, in practice, what I’d like to see before I even consider using Pijul for any project is some serious tag management. Use cases: create a tag (=unambiguous snapshot of the code + history of all the patches included), list tags, see the patches included in a tag, see all tags that include a patch, diff between tags, update a tag (ideally with preserving the history of updates).

As I understand, these features should be (mostly) supported by Pijul’s internal model. But, right now, pijul tag is almost undocumented, and pijul dependencies is not documented at all, and tags are nowhere to be seen in Nest. If I start a new project in Pijul, how can I reliably manage releases?

#2

Hi kyegupov,

As you i’m currently discovering Pijul. Please remember that this project is still in alpha phase and that there is still a lot of work to do.

Regarding your question:
pj dependencies --help and pj tag --help give you some informations.

Here is my understanding and a kind of “rough” solution, awaiting a more robust from the pijul’s dev team

pij tag will ask you a name for a tag. You can use some convention in the name i.e. version=1.0.
Then a new parch is created and get all free patches (heads) in your current state of the project (It’s similar with Mercurial DVCS).

With pij dependencies you will be able to check that all the dependencies which contribute to build your snapshot are linked directly or by translation.

There is still not any command available to list your tags however you can simply list all your patches and grep them with your conventional prefix (version=).

If needed you can simply restore this snapshot with pijul fork.

I’m aware that it’s a bit twisted, but all what is needed is already in place to fulfill this requirement.
It’s not really linked to the snapshot vs patch design model.

I also have read somewhere that the dev team is thinking about another way to achieve that by explicitly saving this snapshot for performance concerns (but still keeping the link to the patch probably)

#3

Hello and welcome to both @kyegupov and @el_titi!

I’d also like to see a better support for tags in Pijul. At the moment, @el_titi is right to say that pijul fork creates a snapshot. Currently, a tag is just a regular (possibly empty) patch, with all patches currently in the branch as dependencies. One of my next projects is to add Pijul support to NixOS, and for that we’ll need to be able to clone a specific tag, list tags, etc.

1 Like
#4

Thank you for your welcome @pmeunier.
I’ll soon introduce myself :slight_smile: