Pushing after merge considered harmful

[Stephen J. Turnbull]

Joseph Wakeling writes:
 > Guy Gascoigne-Piggford wrote:
 > > I wonder how much of this is just due to different expectations.
 > >  Distributed seems to come with the implication that all branches are
 > > equal,

I don't think that's true.  It is true that Tom Lord wanted that to be
true in Arch and designed Arch to make it possible.  I suspect that in
the case of git Linus just threw away "mainline" as something that was
a real PITA in the CVS implementation, and not needed in the workflows
he envisioned using himself.

 > This is where one needs to emphasise strongly Linus Torvalds' very good
 > point in his 'tech talk' on git: in DCVS, the definition of 'mainline',
 > or of a hierarchy of branch importance, is a _social_ decision, not a
 > technical one.

I don't think this shift in emphasis has much to do with *D*VCS, it's
just a matter of supporting branching and merging well and not
bothering to implement the access control required to automate
gatekeeping.  But Bazaar + PQM proves that implementing hierarchy is
possible in a DVCS, and I'll argue below that a fairly "democratic"
organization is feasible under Subversion (though it would be very
fragile in CVS).  The real issue is just that historically, CVS (and
RCS I guess) didn't support merging properly and gave special status
to the trunk.  But that's a detail of the ,v files AFAIK.

AFAIK. Subversion, for example, gives no special status to the trunk.
It really doesn't much matter whether you merge from (social) trunk to
branch or vice versa.  What does matter (in svn up to 1.4, anyway) is
that you really don't want to have anything more complex than a star
topology in which you create feature branches, then merge it back in
to the branch they sprouted from.  Merges should always go in one
direction because Subversion does not implement merge tracking well
(again, up to 1.4, I haven't paid attention to it at all since then).

But I don't think Subversion cares whether you do

0 --- 1 --- 2 ... trunk
       \     \
       R1    R2

(where the Rx's are release branches each sprouting from a long lived
trunk) or

0 --- D1 --- D1R
       \
        D2 --- D2R
         \
          ...

(where the Dx's are development branches each sprouting from the
previous development branch).  The second topology does not work in
CVS, I can testify to that!  If it does work in Subversion, you could
imagine a non-hierarchical project organization where instead of
having a Linus, you have a bunch of co-equal folks, each managing a
release candidate branch with idiosyncratic features, of more or less
equal status to the others.  At any given point of time, one may
become the obvious nominee for the next release, you appoint its
keeper as release manager, and after the release everybody else merges
that branch into their own and the competition starts again.

This is wasteful of labor, I suspect; the point is that I don't think
Subversion would make it any harder to do that than git or Bazaar
does.  What git or Bazaar does is allow much more flexibility in
cherrypicking others' features into your branch at an intermediate
stage, thus supporting more frequent convergence than Subversion can,
by itself, anyway.

However, add-ons to Subversion can make more flexible merging (ie,
cherrypicking) manageable.  Python itself used Subversion that way
with the help of an add-on, called "svnmerge.py" IIRC.

 > Consequently, that means that people have to take a heightened social
 > responsibility for preserving such a branch hierarchy if they want it.

Anything that people can take responsibility for can be implemented in
(sufficiently complex) software.  In the case of VCS, preserving
branch hierarchy isn't even all that complex; you just put a watchdog
(human, like Linus, or automatic, like PQM) on the hierarchically
important branches which deserve long-lived well-known URLs.