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

[Jeremy Fincher]

On Feb 17, 2005, at 5:16 AM, Nathaniel Smith wrote:

> I need to go to bed and sleep on this, but some random, not quite
> integrated thoughts:
>   -- we shouldn't think of this as solving the current "branch names
>      should be global" maybe-problem; it mitigates it a bit, by making
>      it easier for people to turn poor choices for branch names into
>      better choices for branch names, but people can still collide
>      their branch names and this is a problem to most of the extent it
>      is in the current design.

In the current design, won't it serious muck up a database if I'm 
syncing and I encounter another semantically different branch with the 
same name?  If that's the case, and this scheme serves to prevent that, 
I'd say that *most* of the problem is handled :)

>   -- how much of the "people keep not choosing unique names" problem
>      can we solve by attempted branch names against the regexp
>      ^.+\..+/.+$, and if they don't match that regexp printing
>      "Error: invalid branch name: should be of form 'host.name/branch'"
>      ?

Oh please no.  Picking good branch names is at its core a social 
problem, not a technological one, and trying to use a technological 
solution is just going to be an exercise in futility.  Enforcing 
adherence to a social policy that is (at least in some cases) 
practically useless is just a recipe for alienating your users.

Despite Monotone's distributed nature, some people will be using it in 
a more centralized fashion, with one main server their their project, 
which hosts only their project, and with which users/developers sync 
only to update the source for that project.  In such a case, I don't 
think it's unreasonable for there to be branches named "dev" or 
"bugfix" or "main", if Monotone has a good way for users syncing up 
with that server to disambiguate the branch name if they need to.  I 
think, in most cases, they won't need to, either because they're using 
separate databases for separate projects, or because they're only 
working on this one project, or because this is the only project using 
Monotone, etc.  Enforcing some sort of arbitrary branch naming scheme 
is just going to corner us into defending a policy that, at least in 
their case, *decreases* usability.

>   -- is the functionality to let everyone have different local branch
>      names, that don't necessarily correspond to their buddy's name
>      for the same branch, a feature?

I think so.

>      is the functionality where we
>      can no longer tell without checking some long hexstrings whether
>      what I mean when I say "branch foo" is the same as you mean when
>      you say "branch foo", really a feature?

Let's imagine both Monotone and Supybot used a scheme simliar to the 
one described above.  If I'm in #monotone talking about Monotone and I 
mention the "dev" branch, which dev branch will you assume I'm talking 
about?  If I'm in #supybot talking about Supybot and I mention the 
"dev" branch, which dev branch do you think the people in #supybot will 
assume I'm talking about?

Anyone who speaks any natural language is *very* skilled at handling 
ambiguity.  I think you underestimate our ability to use context if you 
think allowing per-user aliases for branch names would seriously hinder 
our ability to communicate :)

>   -- how much will these issues be affected if we add in a security
>      system that lets project leaders specify on a per-project basis,
>      "keys foo, bar, and baz get to commit to branch ___.main; for any
>      key X, key X is allowed to commit to any branch under branch
>      ___.sandboxen.X; ..." etc.?  (I think of this because of someone
>      suggesting that renaming is important because how should they
>      know what the right name to use is?, and such a file could
>      provide such policy in a structured way.)

I would think that security measures should be associate with the 
branch ID, of course, not the branch name.  (The would also, ideally, 
be in the database, so I, as a user, could figure out where I'm allowed 
to commit, etc. just by querying the database).

Jeremy