[Top][All Lists]

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

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

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

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

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


reply via email to

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