monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] branching policy


From: Nathaniel Smith
Subject: [Monotone-devel] branching policy
Date: Thu, 15 Jun 2006 04:23:34 -0700
User-agent: Mutt/1.5.11+cvs20060403

(CC'ed to monotone-devel)

>From #revctrl:
<bram> hey everybody
  so, in the hell freezes over department...
  at work we're looking to switch version control systems, and for a
  variety of reasons no current version control system is acceptable
  for what we want, although codeville, monotone, and mercurial come
  close, but all fail in fairly substantive ways
  so what I'm probably going to do is write a bunch of scripts which
  wrap subversion based on my newfangled theory of branches based on
  3-way merging 
<bram> but basically I want something with centralized (or federated)
  access control, persistent branches, and a very particular UI which
  has to do with safe merging between branches, and none of them
  provide it
  basically, there's a spanning tree of branches, and you can pull
  between adjacent ones (but pulls fail if someone else does a pull
  first) and you can re-neigbor under certain reasonable circumstances
<bram> by the way, it turns out that subversion is an extraordinarily
  powerful tool, but its interface is both far too powerful and far
  too raw to be advisable for everyday use unwrapped
  if you aren't using it like CVS then it's more like the back end to
  a version control system than an actual version control system

You didn't give your full critique, so maybe there are other things
you aren't mentioning, but on the things you did mention... I'd be
very interested in hearing more about your exact use case, and curious
if you've considered using monotone instead of SVN for the backend?

We've always cared a lot more about workflow than versioning
mechanics.  Not that you could, err, tell from talking to us.  But
really, getting versioning right is just a means to an end.  We're
starting to make noises now about figuring out how to sit down and get
things like distributed access control and branching policy working;
there are some (telegraphic) notes at:
  http://venge.net/monotone/wiki/VersionedPolicy

So I'm really curious to hear about your real use case, and I think
there could be some advantages to using monotone for it:
  -- your work provides implementation experience for a more general
     solution (i.e., has benefits for everyone, not just your company)
  -- you can work against a more capable backend -- e.g., we're
     shipping *-merge in stable monotone releases these days.  I know
     it's not your favorite scalar merger :-), but it's proven
     extraordinarily stable so far, and we have full support for
     file/dir renames, all conflict cases, etc.  No merge-in-workspace
     yet, but we have a Google SoC student who will be starting work
     on that in the next few weeks.
  -- we both know that in the long run work on SVN is a dead end.  In
     contrast, we monotone folks are actively interested in supporting
     use cases of this general nature.  I can't guarantee that we'd
     build support for your exact policies in directly (esp. since I
     don't know what they are yet!), but we want to build the pieces
     needed to support user-specified policies too.  So there should
     be a migration path from doing everything by hand, to doing
     things with tool support, and using a modern tool in both cases.

-- Nathaniel

P.S.:

<bram> (by the way, if njs could say whether the LCA is 'the node which is an
  ancestor of both nodes being merged which has no descendants which are
  ancestors of both nodes being merged' I'd much appreciate it) 

"Least" has been (ab)used to mean a lot of things by us VCSers.  My
personal preference is to just standardize on the mathematicians's
terms, they're sensible and have vastly more history behind them then
we can manage.  So the terms I prefer are:
  "least": "the node in a set which is less than every other node in
     that set", any set has either 0 or 1 least elements
  "minimal": "any node in a set which has no other node that is less
     than it"; this is different because DAGs give partial orders, not
     full orders, so you can have nodes that are incomparable.  Any
     finite set has at least 1 minimal element, but it may have
     arbitrarily many.  (This is the definition you give above,
     except maybe that your phrasing suggests that minimal nodes are
     always unique.)
  "nearest": any node you find by using some sort of path-length
     metric.  This is generally a stupid idea, but it is one of the
     ways that VCSers have used "least"...
See also http://en.wikipedia.org/wiki/Order_theory .  To turn this
into "<X>CA" versions, just take the set of common ancestors to be the
set under consideration.

Since we deal in finite sets, a very useful property is that iff a
node is least, then it is the unique minimal node.

The example that may make all this jargon click is, the problem with a
criss-cross merge (and the definition of one!) is that there are two
minimal common ancestors, and thus no LCA.

Minimal is the deep and interesting property.  Monotone has an
operation we call "erase_ancestors" that basically just computes the
minimal elements of a set, and it turns out to be handy all over the
place; both internally and when exposed on the command line for
scripting.  "Heads" means "minimal elements of a branch", for
instance.  (It's interesting that just like it took us all a bunch of
tries to figure out the right definition of "LCA", back in the mists
of time it took us monotone folks a bunch of tries to get the
definition of "heads" right!)

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen




reply via email to

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