Maarten Brock wrote:
> In response to Scott's reply on the user list (see below):
> I think subversion is a lot better than cvs, but I doubt the outage is in
> the equation. This can probably happen to subversion just as well. Also
> the SF team promised the 4 hour delay would disappear for cvs in the
> near future.
The Subversion servers are currently configured such that it takes more
than a single point failure in the system to cause a system failure. The
CVS servers are susceptible to single-point failures. However,
apparently SF is addressing this issue.
> I'm glad someone already experienced just volunteered to help with
> the transition if we agree to have one ;-)
You mean do I have the guts to click on the CVS->SVN radio button in the
admin page? :) It took me a week of discussing with others on whether or
not gpsim should switch over. It took minutes to actually make the
> But before that I would like to see some discussion on it. My gutt
> feeling says we should do it but I prefer to see some good arguements.
> And then there is priority. I think releasing a new version of SDCC
> should have a higher priority than changing our source code control
> system right now. And for that I would like to postpone any transition
> until after the release.
I think postponing a transition over to SVN until after the next release
is a good idea (assuming the next release is imminent).
Here's the thread on the gpsim mailing discussing the transition:
In addition here's a response Eric Smith sent to me privately:
>Is there anything specific thing makes Subversion better than CVS in
> your opinion?
I typically look at it the other way. If I was using Subversion, what
might make me what to switch to CVS? And the answer is "nothing".
* handles renaming of files and directories
not ideal yet, expected to be better in 1.4, but already
much better than CVS which can't deal with it at all
* atomic commits
* faster creation of tags and branches, O(1) instead of O(n)
* branches and tags are identical instead of being separate concepts
* doesn't use the confusing CVS file revision numbers
* each commit has a unique version number, so you can use that version
number on a checkout or update to get the state of the entire
tree at that point, rather than having to figure out what
date & time to use
* metadata versioning
useful for tracking merges, though that is expected to be
done automatically in a future version of Subversion
* better hooks for script integration on server
* Subversion library has well-defined APIs for use from programs and
* better client/server architecture supports multiple access protocols
* doesn't have a sequential revision number for individual files. In
other words, with CVS, the revs of a file are 1.1, 1.2, 1.3, 1.4, etc.,
while is SVN, they might be 37, 62, 118, and 123. At first this
seemed a bit annoying, but over time I've decided that the Subversion
approach is actually better
* doesn't use "changesets" as a first-class data type like Bitkeeper,
Git, and other distributed version control systems. But then, neither
did CVS. There's an SVK wrapper if you want that model, though.
SVN maintains a local copy of the repository. This makes it much faster
than CVS for doing things like diffs. However, this repository can be
quite large. For gpsim it's about 45M.