(Not cc'ing arch-users because, last I checked, it doesn't allow posts
from non-subscribers, and I don't wish to subscribe.)
On Sat, 2003-03-15 at 23:35, Tom Lord wrote:
> Let's, suspending our disbelief for the moment, on both these lists,
> take the latest and greatest bk flamewar on lkml as indicative of
> "where we should (both) be for 1.0".
No. I don't think we should be targeting the Linux kernel's current
developer model. It is an albatross among open source projects and it
does not produce good results. I've written a document about this
(http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot, which isn't as
much of a screed against Bitkeeper as the title suggests), and the
latest flamage allows me to go a little further.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/0130.html gives
some reasons why a version control system focused around highly
decentralized development is really hard. Naturally, Larry has a vested
interest in making Bitkeeper look like irreplaceable voodoo black magic,
but many of his points are valid. And my answer is: so don't do it.
You'll never successfully hide all of that complexity from the user, and
contrary to Linus's rabid opinions, the users really should be using
centralized version control. It yields better results.
Not every Subversion developer agrees with me on all of those points, of
course. And after 1.0, partial repository replication and/or
cross-repository merging or some other combination of features will
probably make distributed development under svn much easier. But I
think just about every Subversion developer does agree that Subversion
1.0 isn't about trying to displace Bitkeeper in the Linux kernel. It's
about providing a compelling alternative for the *BSDs and Mozilla and
Apache and the thousands of Sourceforge projects which use CVS and like
its basic operational model but hate the details and limitations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 16 20:47:13 2003