[Monotone-devel] Re: code review in practice

[Bruce Stephens]

"Evan Martin" <address@hidden> writes:

[...]

> Regarding codereview branch names: rather than being careful about
> naming different branches (and without using a sequence number),
> it's more in the monotone style to just name the branch after a
> sha-1.  For example, you could take the revision id itself as the
> branch name.

IIUC, the current branch and key naming is regarded as an unfortunate
mistake: the intent is that monotone should use hashes to uniquely
identify branches and keys, and the names would then be more easily
changable.

I guess for this application it might be appropriate to forget
altogether about a branch name: that is, after the branch has been
approved and propagated, somehow its name would be marked as no longer
valid, or something.  (Doing this would require management branches,
or something.  Since you'd want to be able to ask about the branch
names from the past---you'd just like that not to be the default when
you do "mtn ls branches".)

I imagine that's something not too far from what workspace-as-branches
systems (and git, which seems to offer workspace-specific branch
names, IIUC, which can naturally vanish as appropriate) provide more
automatically.  I think it could provide much the same workflow and be
quite convenient to use.

So I think I'd suggest, for the moment, using meaningful branch names
(perhaps with a counter or something to avoid clashes), on the
assumption that one day monotone will use hashes for branches and
things will make it all much more workable.

I fear that if one started explicitly using hashes you'd end up with
tools stuck with that, with the hashes being turned into more hashes
by monotone to identify the *real* branches.

Maybe this is a useful hook for attacking management branch
functionality: what does monotone need in order to provide branches
whose names can be made invalid (such that the names can be reused by
new branches)?

[...]