[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: user-friendly hash formats, redux
From: |
Oren Ben-Kiki |
Subject: |
Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Wed, 8 Dec 2004 00:45:39 +0200 |
User-agent: |
KMail/1.7.1 |
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
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Jon Bright, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Logan Sackette, 2004/12/07
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/07
- [Monotone-devel] Re: user-friendly hash formats, redux, John S. Yates, Jr., 2004/12/07
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, derek, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/08
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Richard Levitte - VMS Whacker, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Jerome Fisher, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Jerome Fisher, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Zack Weinberg, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/07
- [Monotone-devel] Re: Re: user-friendly hash formats, redux, John S. Yates, Jr., 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/07
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Emile Snyder, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Kevin Smith, 2004/12/05