[Phpwm] CVS or Subversion?

[David Goodwin]

Peter Graham wrote :
> Following the informative discussion on the list last week regarding CVS
> and Subversion I have decided that I am definitely going to start using
> one of them.
>  
> My friend who also develops PHP websites fulltime recommended using CVS
> over Subversion here is his quote:
>  
> "The main advantage of CVS is that they're plugins for just about
> everything to interface with it, which makes life less hassle some"
>  
> I was under the impression that Subversion is generally regarded to be
> better? So decided to start using it, however I discovered my
> Development Server at work didn't have Subversion installed. I went to
> install it using yum but forgot that changes to our work proxy has
> stopped yum working correctly on my Dev Server.
>  
> So now I am unsure what to do, go with CVS which is already there, or
> install Subversion manually?

Hi,

Right, fully armed from a subversion talk at FOSDEM, how about :

1) CVS doesn't handle large files very well (it's easy to DoS a server
if two people decide to check out that 600mb iso that really shouldn't
be there...)

2) CVS sends a full copy of the locally modified file to the server,
where as subversion can do a local diff as it has a local copy in
$pwd/.svn somewhere. Therefore subversion requires a lot less bandwidth.

3) Subversion handles binary files far better, because it can do binary
diffs between them. CVS on the other hand stores a totally new copy of
the binary file for each instance.

4) if($platform=="Windows") - there are 3rd party plugins to allow you
to do a diff on .doc documents through tortoise(i believe).

5) Subversion provides a library and can use either : ssh, file, webdav
or it's own protocol. This means :
	- it's far easier for third party tools to integrate with it (as
	  they don't have to parse output from spawning an external
	binary like 'cvs' ). This makes it far easier to write a svn
	client or integrate with svn.
	- svn is far more secure
	- svn is far more network efficient
	- svn is more accessible
		- http://foo.bar/svn/my_repository/path/to/a/file.php
		- or via ssh
		- or via file:///var/svn/my_repository/

6) Subversion is atomic - if a commit fails half way through (e.g.
network issues) the repository won't be in a mess.

7) Subversion uses a global revision number for each commit, rather than
on a per file basis - which makes it easier to say "Revision 5555 was
good" than "It was ok on Thursday morning" (CVS). (Obviously you could
also tag..)

8) Subversion makes tags and branches easier - in that it's just a case
of 'svn cp' a tree. This makes it easier from a mental perspective, but
does require you structure the layout of your repository to e.g. contain
:
  - /trunk
  - /branches
  - /tags
(e.g. See http://svn.edgewall.com/repos/trac/ )


Subversion doesn't yet handle the double merge problem (i.e. you've been
working on a branch, merge to the trunk, do some more work on the branch
and then merge back to the trunk again - currently svn will try to merge
the same stuff twice, which causes problems.). If you're likely to find
this a problem, then you're probably developing quite well.

The only thing to try adn maintain with a version control system is to
commit on a per-bit-of-work-basis, and not on a time basis (I still
don't manage this normally). As then you can e.g. start merging stuff
on a per patch basis, which can make it (version control) far more powerful 
if in a larger project.


David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]