We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 173

Summary: Move to subversion
Product: SDL Reporter: Ryan C. Gordon <icculus>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: enhancement    
Priority: P2 CC: cwalther, max
Version: HG 1.2   
Hardware: All   
OS: All   

Description Ryan C. Gordon 2006-03-22 04:18:46 UTC 
Figured I'd put this into Bugzilla as a wishlist item while there's some really nice development momentum going on.

Subversion has proven to be a really sweet upgrade over CVS, and it would be nice to use it with SDL, too. Among the other things I like about it, since there's one global revision for the whole repository, you can close Bugzilla entries with "Fixed in revision #927", or whatever, and have it mean "the exact state of the source repository at revision 927"...since CVS does revisions on a per file basis, it's hard to group checkins, or cleanly jump between revisions when there are large changes in a given checkin.

Plus a bunch of other goodness, most of the biggest ones listed here:
   http://subversion.tigris.org/

They also supply scripts to convert an existing CVS repository to Subversion without losing your version history (they work quite well...several icculus.org projects have been pushed through them, and they are smart about collecting files committed with the same timestamp/comments into single revisions).

--ryan.
Comment 1 Sam Lantinga 2006-03-22 04:33:33 UTC 
I don't suppose it takes care of the chicken and the egg problem of SDL_config.h? :)
Comment 2 Ryan C. Gordon 2006-03-22 04:38:34 UTC 
No, unfortunately....if you explicitly ignore a file that's in subversion with their equivalent of .cvsignore, it'll still list it as modified, like CVS.

--ryan.
Comment 3 Max Horn 2006-03-22 12:23:30 UTC 
I would like to state my support for such a move. It's just much more comfortable, and thigns like being able to rename and move files for real are just great !

We recently moved ScummVM to Subversion (now that SourceForge.net offers it), and we haven't regretted it in any way so far -- quite to the contrary :-).

We did use the cvs2svn script but applied lots of manual work to get an improved conversion (doing things that an automated tool simply can't do), see <http://wiki.scummvm.org/index.php/CVS2SVN>
Comment 4 Christian Walther 2006-03-25 04:20:28 UTC 
I'd welcome a switch to Subversion too. It solves a lot of the historical quirks of CVS. http://www.pushok.com/soft_svn_vscvs.php and http://www.pushok.com/soft_svn_vscvs_1.php list some (supposed) disadvantages of Subversion, but the only one of them that I consider valid is that there is no concept of a tag as a symbolic name for a revision number, which is no big deal IMHO.

If you're going to use cvs2svn, do a test run and examine the resulting Subversion repository closely. When I converted my SourceForge project (http://pipmak.sf.net/), I found that it handled branches in a weird way (I don't remember how exactly, but it was different from how the branch would have been done if the project had been in Subversion all along. I suspect that it was in fact CVS that handled it in a weird way, and cvs2svn had no choice but to replicate it). I ended up doing a lot of manual changes to the Subversion dump it generated (also because I wanted to retroactively add some files that I had kept outside of CVS because of its poor binary file capabilities), but that wasn't a big problem as the dump was only 11 MB (in about 50 revisions).
Comment 5 Sam Lantinga 2006-04-26 17:14:48 UTC 
Done!  http://www.libsdl.org/svn.php