I was talking with somebody about Pijul, and the issue of “state at point in time” came up. Then it occurred to me that this is distributed source control, so that’s not a well defined question. There can always be patches missing from people who haven’t synced. The only timestamp that makes sense on a patch is creation time. So at most you can ask “of the changes I have, which were written before some date?” This you can find out by looking through Pijul’s change log. When it does come time to sync changes, Pijul is well-behaved. It simply adds the patches. You don’t have to merge back and forth or rebase. Conflicts can be dealt with locally, or remotely. Anyone can write and push the conflict resolution changes.
A release, on the other hand, is well-defined. It is a specific set of changes to be distributed under some name and/or version number. To store such a set of changes, a channel is the natural choice. Whenever you need to access a release, you can just switch to or create a channel with only those changes.
Then there are tags. Pijul tags are like Git commits: the state of the channel is bookmarked and combined with a message, author, and timestamp. This is neat, but there are several limitations. You can check out a tag into a new channel, but not apply it to an existing channel. To access and use tags you have to be in whatever channel they happened to be created in. You can only tag the current state of a channel, not arbitrary changes in it, so if you want to sign a point release for a previous version of your app, you have to create a new channel. So they aren’t at all like Git tags, and they don’t match the spirit of composing patches. I would like to see something like it that isn’t tied to channels. (Basically, immutable channels you can sign).