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

[graydon hoare]

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)

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

 - when you sync, absorb the other person's branch names unless you
   already have a branch with that name *or* a branch with that ID;
   in either case emit a nice warning and abort the sync

 - when you rebuild, for each branch (ID,NAME), create a new branch
   (NEW-ID,NAME) which has the same human-friendly name but a new
   random ID

 - 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..)

 - 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"

this all sounds to me like a nice tidy-up, and avoids introducing any 
new concept such as epochs. the only reason I'm not really jumping into 
implementing this is that it'll be disruptive and involve a lot of 
hacking. a few weeks of hacking. we're already sort of a month behind 
the "nice" schedule we would like to follow for 0.17. and I'm going on 
vacation, so I won't really have a few weeks of spare hacking for some time.

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.

  2. delay 0.17 as long as it takes to rewrite the cert format and
     make branches into random IDs, possibly weeks or months, and
     release that when we're good and ready.

  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)

any preferences?

-graydon