Re: [Docutils-develop] Development strategy

[Martin B. <mar...@gm...>]

On 8/17/05, David Goodger <go...@py...> wrote:
> [Felix Wiemann]
> >> 2) Subversion's **branching support** is bad.
> >>
> >>    * There's no merge-tracking in SVN.  Branches getting
> >>      out-of-sync are a pain because Subversion doesn't track which
> >>      changes have been merged.
>=20
> [Martin Blais]
> > Indeed, and a major flaw in Subversion.  You can kind-of track your
> > last merge by hand by keeping a dotfile in the root of your checkout
> > though.  This is what I do (error-prone, but it kind-of works and I
> > haven't lost anything yet.)
>=20
> Can you elaborate?  This may prove useful.

Essentially, when you merge you merge changes on a revision branch
from rev. A to rev. B into a file.  Merge tracking means that the
system remembers that you merged from the common ancestor of the file
and rev. B into the file (in ClearCase terminology, this is called a
"merge arrow", probably because they provide a tool (xlsvtree) that
allows you to view the revision tree and merges that occured--and
trust me, in a team of 60 where people are merging stuff left and
right and you need to figure your way out of a hairy situation, that
tool is so useful to get a clear picture of what happened).

The fun thing with those merge arrows is that when you have to
merge/update some code, the system can use those to figure out the
minimum list of patches to apply to bring the file up-to-date (i.e.
the common ancestor).  With subversion, there is no such merge
tracking, i.e. YOU have to tell it which patches (i.e. start and end
revisions) to merge into your branch.  You might screw up, either by
remerging old changes which you've edited by hand, or by forgetting to
merge some revisions.

Now, assuming a setup/policy where you have a main branch (subversion
folks call this "the trunk" by convention, of in ClearCase, the "main
branch") and some development branches, while your branch is "alive",
you are essentially always merging changes from the main branch into
your branch, this is a matter of policy only.  Tracking by hand means
remembering which was the last revision you merged into your branch,
and when you need to update again you start from this revision.  Since
in Subversion the revisions are global for the entire repository, it
suffices to remember the "revision" for the whole checkout, which you
can do by editing a dot file in your checkout (this is not the case
for CVS nor ClearCase, each "element" (file or directory) has its own
revision number list).

Note that it would be possible to build a simple wrapper on top of
subversion which assumes those policies and maintains that file for
you, under version control, restricting the set of operations that can
be done (of course the user can still use svn and screw up the
system...  this is one of the many reasons ClearCase is so much better
than all of these other systems, it allows setting hard policies on
the server side which you, as a user, cannot break--so this works
where the people are physically located in the same place and can
informally enforce those kinds of conventions.  Unfortunately you need
a full-time employee to manage a decent-sized ClearCase
deployment...).

I started work on a system that does that kind of hacky tracking on
top of Subversion, called "oversion", but have not got around to
finishing it yet.  If someone will be hire me to do that, I would be
happy to solve that problem for money (I've done it in the past over
CVS, and the system works pretty well and is used by a team of 6-8
developers that do branch-style development over CVS today--at this
point they see no real need to switch to something else, problems are
rare and usually easy to fix).

Part of the problem and solution lies in defining policies for
branches/releases/tags, etc.  Subversion has not enforced specific
policies (they "copy" operation is cheap and flexible) and I think
without constraining the capabilities of the their system it may be
non-trivial for them to add proper merge arrows to their system
(although I'm speaking without having read any of their design
thoughts, but it seems to me that merge tracking has to be laid out in
the basic architecture of an SCM system to be implementable... maybe
they have some grand plan though, don't know).

If you're interested in more details about this interesting problem,
the full monty / meta / zen of SCM policies setups can be found in
this chunky article:

http://www.cmcrossroads.com/bradapp/acme/branching/

(that's a rather obscure document to read, but it's very rich with
that kind of  information if you ever need it)

cheers,