Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.)

[Jeremy Fincher]

On Feb 17, 2005, at 12:06 AM, graydon hoare wrote:

> Derek Scherger wrote:
>
> > Some way of syncing branch rename operations would be needed though 
> > so that if two databases have disagreeing names with the same hash 
> > (i.e. branch fred with hash 1234 verses branch barney with hash 1234) 
> > there's some way for netsync to resolve this.
>
> yeah, this is all good thinking. in a sense this is similar to the 
> situation we've got for public keys. I'd be willing to "fix" this, 
> even go in the direction you're hinting at. specifically, the idea 
> would be:
>
>  - make branches random IDs
>
>  - iow, make branch certs apply to IDs, not human-friendly names
>    (aside: also encode the key IDs in certs as coming from key IDs,
>     not human-friendly key names as we currently do .. basically
>     redesign certs to clean them up a bit)

I think this is a great idea.

>  - make each database maintain a 1:1 mapping between branch ID and
>    human-readable name

I'm not sure if this is necessary, or if it's a good thing to enforce.  
People *will* pick duplicate branch names.  There is no doubt in my 
mind that many people will have branches named "bugs" or "main" or 
"dev", etc.  No matter how many times we say, "Pick a globally unique 
name!" people still will not do so.  I think, rather than have the 
database *enforce* unique human-readable names, we should instead have 
the user disambiguate such collisions himself.

Of course, this wouldn't be very user-friendly if the user had to 
disambiguate branch names *every* time, so I suggest that we cache the 
user's decision in some way that's easily editable/readable by the 
user: either a dotfile in his home directory or a file in MT/.  We 
could keep a mapping of human-readable names to random ids, and use 
that first when we're given a branch name by the user.

A nice side effect of that functionality is that the user could use 
shorter names for branches, if he so chose.  Also, in the case that 
Alice wants to work with Bob's "dev" branch and Cindy's "dev" branch, 
she can have a different "nickname" for each and work with both 
perfectly fine.

We could use the same scheme for mapping public key human-readable 
names to the actual public key.

>  - add a "branch rename" command which lets you correct for the
>    case where you chose a bad name (as well as a "delete branch",
>    which is easy to do now we just don't do it..)

That's one of the nice things about the method I propose; if a user has 
setup a nickname for the branch, he won't be bothered at all by a 
rename.  Behind the scenes, his database would accept it, but since the 
randomly generated *actual* branch name didn't change, his aliases will 
continue to work as before.

>  - if you and a friend happen to make the same branch name X which you
>    *want* to reconcile, but accidentally generated two versions of it
>    in isolation with different IDs, put a chapter in the manual about
>    this. the suggested fix is "rename one as X.tmp, sync, then
>    merge X and X.tmp and delete X.tmp"

With user-overridable aliases, he could just insert a temporary alias 
for the other branch, merge the differences into his own branch, and 
remove the old alias.  No database pollution at all.

> perhaps we should put it to a vote. the reason we're delaying 0.17 at 
> the moment is that we're working on epochs. this scheme would replace 
> epochs. so it produces 3 possible futures. which would y'all perfer?
>
>   1. release 0.17 without any epoch support, do a big smelly email
>      telling everyone to pull from our rebuilt database just like with
>      0.16, perhaps also with a protocol number bump again, and have no
>      particularly better way of avoiding the breakage of old and new
>      revision graphs colliding. then work on this branch-as-ID stuff
>      for 0.18.

I prefer this idea.

>   3. finish working on epochs, release 0.17, and forget about this
>      crazy branch-as-ID stuff (possibly because it has some horrible
>      flaw I haven't forseen)

I doubt it has some flaw you haven't foreseen.  At least, I hope not, 
because this is the same solution I thought of when I was thinking 
about the issue of globally unique branch names :)

Jeremy