[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 :)
Jeremy
- Re: [Monotone-devel] Ideas and questions., (continued)
- Re: [Monotone-devel] Ideas and questions., Derek Scherger, 2005/02/15
- [Monotone-devel] bash completion, Olivier Andrieu, 2005/02/15
- Re: [Monotone-devel] Ideas and questions., Bernhard Reiter, 2005/02/16
- Re: [Monotone-devel] Ideas and questions., Joel Rosdahl, 2005/02/16
- [Monotone-devel] Re: Ideas and questions., Bruce Stephens, 2005/02/16
- Re: [Monotone-devel] Ideas and questions., Derek Scherger, 2005/02/16
- [Monotone-devel] renaming branches (was Re: Ideas and questions.), graydon hoare, 2005/02/17
- Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.),
Jeremy Fincher <=
- [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.), graydon hoare, 2005/02/17
- Re: [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.), Nathaniel Smith, 2005/02/17
- Re: [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.), Jon Bright, 2005/02/17
- Re: [Monotone-devel] Re: renaming branches, Richard Levitte - VMS Whacker, 2005/02/17
- Re: [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.), Jeremy Fincher, 2005/02/17
- Re: [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.), Jeremy Fincher, 2005/02/17
- Re: [Monotone-devel] renaming branches, Richard Levitte - VMS Whacker, 2005/02/17
- Re: [Monotone-devel] renaming branches, Jeremy Fincher, 2005/02/17
- Re: [Monotone-devel] renaming branches, Richard Levitte - VMS Whacker, 2005/02/17
- Re: [Monotone-devel] renaming branches (was Re: Ideas and questions.), Julio M. Merino Vidal, 2005/02/17