[mnet-devel] Subversion vs DARCS (was: Moving sf.net CVS to cryptomonkey.net Subversion)

[Sean E. Russell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cross posting.  What fun.

Zooko said:
> Good to know!  I think Subversion is less stable than CVS, and that could
> give us problems, but it might be worth the risk of using Subversion instead
> of CVS in order to have convenience and security for the server admin.

This hasn't been my experience.  I've been using Subversion exclusively for 
two years; in that time I've had no data loss, and in the past year I haven't 
had any trouble with the server at all.  We're using Subversion on at least 
two projects I know of at Glaxo-Smith-Klein (a large pharmaceutical company).  
The databases are easy to back up, the database dumps are surprisingly 
compact (and compress really well), and we're very happy with the project.

That isn't to say that Subversion doesn't have limitations.  Repository access 
control granularity is, frankly, non-existant.  The potential of WebDAV as a 
transfer protocol is largely unrealized; until we have WebDAV 'post' commits, 
the use of WebDAV is largely irrelevant.

I see DARCS and Subversion as addressing two different problem spaces.  DARCS 
lends itself much more to a distributed development model, where there is no 
authoritative repository.  Subversion is much more centralized.  This makes 
DARCS more appropriate for open source projects, whereas Subversion is more 
appropriate for a corporate environment.  Subversion has a very clean design, 
with a short learning curve; in SVN, everything is a URL, and all operations 
boil down to copies, deletes, and updates.  This is very powerful when 
applied to tagging and branching.  DARCS has a much better patch-oriented 
paradigm, allowing change sets from different branches and from different 
repositories to be more easily merged.  Currently, SVN has no 
cross-repository merge support.  SVN commits are atomic, which is a very nice 
feature; I don't know what happens to a DARCS repository if a changeset 
import or commit fails.  SVN scales well for large projects; DARCS may not.  
DARCS has granular access control, based on PKI; SVN relies on Apache for 
access control, and it is insufficient to provide granularity.

They both have their advantages for particular jobs.  I do like DARCS 
distributed model, and the patch oriented change management.  DARCS also has 
a better access control model.  I prefer Subversion's usage design, and the 
potential to use WebDAV as a commit interface.  The stability of DARCS, as 
compared to Subversion, is up for debate, but from my experience, Subversion 
is more stable than DARCS.

> I don't think this would be a problem.  Real merge conflicts are rare, and 

Hm.  In your project, or in general?  On a 4 person team of developers in a 
project at GSK, we get commit conflicts weekly, and the number of merge 
conflicts rises geometrically the longer branches go unmerged.

I agree that conflicts aren't a big deal, though.  We consider commit 
conflicts to be opportunities for communication :-)  However, this is a weak 
point in the commit-via-email architecture, and it would be nice to have this 
addressed.

> Hm.  That's a good point.  It would be a bit tedious, and people who wanted
> to 

We haven't found branch merges in Subversion to be difficult at all, once they 
are understood.  The problem we find is in getting people to learn which 
deltas to merge from.  The key is to merge using the diffs between the 
current branch revision and the revision at the point *where* it branched, 
into the branch where you want the changes.  For example, given:

	0	->	1	->	3	->	5
			|
			v
			2	->	4

merging from 4 to 5 you'd want -r 2:4 into a WC containing 5.  Most people try 
to merge 5:4 into 5, or something like that, the first time.

Your example:

> For example, suppose that you were working on branch_twisted while I was 
> working on branch_ent, neither of which was the HEAD branch.
> 
> Now suppose that I want to get the current Twisted integration merged onto 
> branch_ent, but you do *not* want the current ent hackery merged onto 
> branch_twisted.  

is easily solved.  You check out branch_ent, then merge the diff from 
branch_twisted from where it deviated from branch_ent (they must share some 
common ancestor) into that checked-out working copy.  If you commit the 
merge, only branch_ent will be affected.

Again, there must be some common ancestor for this to work, but Subversion 
does not allow cross-repository merges, so the constraint is already a given.  
If you're going to criticize Subversion's merging capabilities, this 
limitation would be much more concrete.

> Bottom line: DARCS promises some delicious features that no other Free 
> Software revision control system has even conceived of, as far as I am 
> aware [3].  However, I haven't tried it yet, and there could well be hassles 
> of administration, UI, or stability that would render it unusable.  I want
> to find out.

DARCS appears to my amateur eye to be very similar to arch.  I'm not aware of 
any significant architectural differences, although DARCS appears to have 
more features, and has a better implementation. 

- -- 
### SER   Deutsch|Esperanto|Francaise|Linux|Java|Ruby|Aikido|Dirigibles ###
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737  ###
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg   ###
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/CYJHP0KxygnleI8RAkUgAKCECb0MYHBrkg3sS4ZWl8YKSIa8OgCguZUT
Es1i/YPgElxewdrJBxdRUaE=
=ujbF
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel