--- Tom Lord <lord@regexps.com> 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.
Can you elaborate, please?
Also, does the arch way force a process on the users?
> 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.
I disagree. Being able to do concurrent development
and, more over, create branches in constant time
promotes multiple lines 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.
Why wouldn't someone be able to do this with
Subversion?
> 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.
Could this functionality be better served by wrapping
Subversion?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 14:11:08 2002