> Task branches seem like they would work as long as you
> don't work on two dependent patches at once. If you
> interleave work on rip-the-VM and rip-the-VM-even more,
> you'll have to do a merge each time you commit changes to
> rip-the-VM.
It's really frustrating reading you guys thrash about issues like this
that have already been solved in arch in a form that is easily
portable to svn.
(Part of the reason I'm skeptical of BK is that Linux is highly unusual
in having a single integrator for a project of that size, and BK seems
to have been designed with the Linux model in mind. Any normal project
would just give commit access to a bunch of developers in order to
reduce the integration burden.)
As time passes, the accurate record of separate changes is a primary
product -- on par with the head revision. That's because forking is
going to become more common and more important (e.g., every large
customer should have their own forks). Just upstream of deployments
are exchanges of change sets.
Replacing a single integrator with a team changes little or nothing --
that team is then the single integrator and people will look to them
to publish both a head revision and a list of coherent changes.
SVN as source code control system is optimized for the "big bag of
programmers" approach to source management: a bunch of programmers
taking turns creating revisions within a single line of development.
arch is optimized for the "change set management" approach to source
mgt.: programmers publishing change sets against well-known bases;
multiple forks integrating those changes to produce competing,
well-known bases.
One natural approach to project management is "change set management"
at the large scale, and (optionally) "big bag of programmers" at the
small scale. You'd have, for example, big bag teams acting as a
single player in a larger change set game.
Adding `svn:' method support to arch's `with-ftp' and writing `svn
publish' and `svn retrieve' would give svn the best of both the
big-bag and change-oriented worlds -- a perfect tool for programmers
playing in big-bag mode in a change-set world. The resulting
combination would have most of the core features of BK -- with just
trivial scripts between there and overtaking BK.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 02:53:31 2002