On Mon, 2002-10-14 at 20:55, Tom Lord wrote:
> > 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.
So explain the solution, and not in terms of arch. A design which
exists only in your head is worthless to the world; a design in your
head reflected only in source code (which you've admitted is hackish) is
only slightly more valuble.
If you've alread written down the design here, great; provide a
pointer. Simplying saying "I've solved this problem" is not
constructive.
> 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.
I don't agree. I see no reason why forking will become more attractive
than it is now--which is to say, done only under duress, and usually
only with small changes necessary for the local site.
Large customers are not swimming in a sea of extra resources. I work
for a largeish part of a large entity (MIT), and my group doesn't have
the resources to make more than tiny bugfixes and adjustments to the
software we use.
> Replacing a single integrator with a team changes little or nothing --
It changes an awful lot. The vast majority of Linux work is not done at
the top of the hierarchy; Linus acts almost purely as an integrator, not
a developer of original code. In NetBSD, somewhere between 50% and 90%
of the work is done by committers, and the integration work is spread
over a large number of people. So CVS works okay for them, despite its
clunkiness. They don't need their tools optimized for a tremendous
integration throughput.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 03:05:25 2002