[Top][All Lists]

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

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

From: graydon hoare
Subject: [Monotone-devel] Re: renaming branches (was Re: Ideas and questions.)
Date: Thu, 17 Feb 2005 03:50:54 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Jeremy Fincher wrote:

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.

I think you misunderstand what I mean. I mean that in one user's database, they would have a 1:1 mapping between an "alias" and a branch ID. other users, in other databases, could have different (or colliding) aliases. but the user would not have either of these cases:

  - 2 aliases mapping to the same branch ID in a database
  - 1 alias mapping to two different branch IDs in a database

I want to prohibit those, at a UI level, because it makes the UI significantly more surprising and hard to predict.

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.

that mapping, which you just described, is the 1:1 mapping I'm talking about. I think it would be fine to keep it in your database, even send it to another user as "advice" when you're syncing. I'm not talking about a global 1:1 relationship, just locally, per-database.

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.

yes, we're more or less talking about the same thing. though, if you ever want to push your work out the wider world, it'd be good to pick a global-ish name at that point.

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.

again, this much is the same between what I said and what you said.

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.

.. I think the only difference here is whether you happen to have two branches with the same alias, or you rename one first. imo not much difference.

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

oh, never underestimate njs' uncanny ability to crush your finest ideas into a paste :)


reply via email to

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