Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Oren Ben-Kiki]

On Tuesday 07 December 2004 21:25, Nathaniel Smith wrote:
> The assumption is that a given user can be trusted to provide the
> unique microbranch identities for her own microbranches?

Sort of. Given that each branch (or fork) has an owner (whoever signed 
the cert creating the branch/fork), then only this user can advance the 
version number of this branch/fork. Everyone else must work on their 
own (sub-)fork and hope the owner merges them in.

So, in such a system, yes, the human owner of the branch (or fork) acts, 
in effect, as the authority for that branch (or fork). Which makes 
sense, thats what being the "owner" means. The system provides defaults 
such that 99% of the time, you just commit and things "do what you 
mean". Specifically, it automatically forks if you (1) create a 
revision inside a branch/fork owned by someone else; (2) create a 
revision in your own branch/fork, but based on a non-head revision.

Sometimes you do need an explicit flag to express your intent as the 
branch/fork owner. For example:

> What happens when I do some hacking on my laptop and some hacking on
> my desktop, and we don't assume that I'm a Perfect Person that always
> remembers to sync before taking the laptop on the bus? (A very real
> example...)

Which seems more-or-less what Jerome also asked. Let's play the 
scenario. You have:

   1 -> 2 -> desktop-wd
         \-> laptop-wd

You hack on your laptop. You commit. Now, do you intend this to be the 
new "main trunk" revision, or do you intend this to be a small fork for 
playing around with some notion you got on the bus? If the latter, say 
"--fork" and there's no problem. Suppose you didn't (you intend this to 
be the new "main trunk" revision). You get:

  1 -> 2 -> 3 (laptop)
        \-> desktop-wd

You get back to your desktop, and commit there as well. Again, do you 
intend this to be the new "main trunk" revision? If you do, surely 
you'll sync and update first, because you *know* you don't have the 
latest one there (you had just created it on the laptop on the way to 
work). So, if you intend to create a fork for investigating some 
feature, say "--fork". You'd get:

  1 -> 2 -> 3 (laptop)
        \-> 3.nathaniel.1 (desktop)

You can later merge the fork if you want; revision ids will not be 
re-numbered, all is well. But, suppose you do neither and commit 
normally, without doing a sync first. In this case, you created two 
version 3s - one on the laptop, one on the desktop:

  1 -> 2 -> 3 (desktop)
        \-> 3 (laptop)

The next time you sync the desktop and the laptop, only one of the "3" 
revisions can be the new "main trunk" head. The other becomes 
3.nathaniel.1. So, Monotone prompts you to choose which one is which. 
That's because Monotone doesn't know your intent - you mean one of 
these to be a fork, and you didn't tell it which one, so it needs to 
ask.

So yes, in this very restricted sense (you not telling Monotone your 
intent) the revision ids are unstable. IMVHO, this isn't a big problem. 
The "--fork" is not a hackish flag meant just for handling revision 
ids. It captures the *intent* of the commit. You _know_ whether you are 
creating a new "main trunk" revision or exploring some side development 
line.

This is in line with what Gordon pointed out - having a "main trunk" and 
"forks" is useful regardless of having stable revision ids. If you 
agree this is useful, then having "--fork" is needed anyway. Having 
stable revision ids is just a happy bonus :-)

Also note that this only affected _your_ revision ids, nobody elses. 
Sure, you could construct more elaborate scenarios where more 
renumbering occurs: you have several desktops and different people sync 
with a different ones and you commit revisions randomly in each and 
don't sync them very often... But still, you only mess up your own 
revision ids. In such a scenario (syncing "not very often"), other 
developers should have their own branches, and are isolated from the 
mess you are making in your own branch.

Given that people don't randomly commit stuff but actually have an 
intent in mind and actively try to achieve it, the <x>.<author>.<y> 
method gives you friendly revision ids that are stable 99% of the time 
and provide a clear expression of the relationship between the 
revisions.

Have fun,

 Oren Ben-Kiki