[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jeremy Fincher
Subject: Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.)
Date: Thu, 17 Feb 2005 03:06:47 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]