My company unwittingly switched from cvs to subversion and now we're all wishing we had cvs back. I know there's tools to migrate history and changes from cvs to svn and there's no equivalent to do the reverse. Any suggestions or ideas on how to do this?
Interesting opinion, I disagree. That's why I posed the question the way I did.
stu
2008-10-01 22:03:41
Funny how no-one agrees with you stu.
Marcin
2008-10-01 22:08:51
Meh, the guy's entitled to use whatever tool he likes, popular or not.
2008-10-01 22:12:47
I don't see anything interesting in what I've wrote, I don't like svn either, personally I prefer bazaar. But really, it's like trading your core 2 duo for a celeron and calling it an upgrade.
Vasil
2008-10-01 22:15:05
+7
A:
Not an upgrade. Do not do this.
Seriously, why would you prefer CVS to SVN? CVS is literally a toy that pretends to allow teams to work without explicit communication. It really is terrible.
Marcin
2008-10-01 21:56:20
cvs handles tags and branches in a more useful way for me than subversion does.
stu
2008-10-01 22:03:05
Or you could learn how to do them in SVN. Seriously, if you have never had a problem with SVN giving you configuration problems, you likely have a tiny project. I suggest that you look at other version control systems if you need something other than SVN.
Marcin
2008-10-01 22:08:09
@Marcin: Take a deep breath, get some perspective, and stop assuming that just because you don't understand the OP's motivation he must be an idiot.
2008-10-02 02:55:04
@Mike F - I'm pretty sure that there is no reason why one would want to do this other than ignorance. Even rolling ones own VCS system based on RCS would make more sense.
Marcin
2008-10-10 22:05:30
Everytime somebody in my office comes to me and mentions how annoying subversion is, I am reminded of this thread. Yes subversion is newer, yes it versions in a database, yes it can do atomic operations, but tags are not tags, they're copies, this makes tagging useless and makes a bigger mess than not tagging at all. I just get so frustrated with it so often, I miss cvs. And this thread. :-)
stu
2009-10-07 19:53:08
+2
A:
when all you have is hammer, everything looks like a nail.
best bet is to learn svn it will make more knowledgeable.
Keith Fitzgerald
2008-10-01 21:59:33
I have two years experience with svn, and 10+ with cvs. Subversion is newer, but for my uses, it is not better. Let's not fight.
stu
2008-10-01 22:02:30
+7
A:
SVN is not great. SVN is better than CVS. If you want to change checkout Mercurial, GIT, Bazaar.
Corporal Touchy
2008-10-01 22:05:40
+7
A:
I don't think the tools exist to go in the other direction, because there's not much demand for it.
If you really must do it, it shouldn't be very hard to write a script that walks through the history of the SVN repo, getting each revision and committing it to CVS.
BTW, I'm genuinely interested to know what problems you have with SVN.
I too am interested in what's so bad about SVN that CVS is preferable: in my experience, SVN is everything CVS is and more!
antik
2008-10-01 22:29:49
Firstly tags. Secondly branches. Thirdly the attitude that the svn developers have about how you should re-learn what tags are so that subversion now makes sense rather than making the tool work in a sensible way. Linus Torvalds did a great talk about git at google and I think mentioned a few things why svn is not so great.
stu
2009-10-07 19:55:21
+3
A:
Your options are probably realtively limited. Remember that active development of CVS stopped a while ago, so there are probably no tools for you from the CVS developers. And since one of the main goals of svn was to be a better CVS, those developers will probably not have expected anyone to move backwards either.
But if you don't like subversion, why not have a look at the more modern distributed systems (git, mercurial etc)?
matli
2008-10-01 22:11:37
+7
A:
So what is with SVN that your company dislikes so much and CVS does better? The designers of SVN went out of their way to make the SVN experience fairly similar to CVS. If you use the Tortoise client as a front end the experience is very similar. SVN gives you atomic commits, which while not quite up to the standard of Perforce is miles in front of CVS.
I do have to sympathise with your plight. I upgraded our development team & IT Team from CVS to SVN. I got all the right python scripts to upgrade all the version history and we have been using SVN happily for nearly 4 years. About three months ago the IT Team leader decided to "upgrade" all his projects from SVN to guess what? That's right, the heavy lifter of the version control systems: SourceSafe!
I would definately stick with SVN or even look at some of the newer distributed systems such as Mercurial. With these systems there is no central server. They rely on being able to branch & merge across dozens or hundreds of peers. You define your own topology, so for example, you would specify a particular peer as being the one that performs daily builds.
Mike Thompson
2008-10-01 22:18:29
Upgrade from SVN to VSS? There is a story worthy of TheDailyWTF behind that comment? Are you still working with this moron?
Anthony
2008-10-02 08:29:42
+2
A:
Agree with Corporal Touchy.
SVN is better than CVS, because it was designed to be - it's roughly the same thing, with some simplications and new features.
With Svn, you can move/rename a file without losing its history; you get safer commits (commits are atomic operations) and global revisions.
Anyway, try to get to know it better before swithing back to CVS and even better, try to really understand your needs as a team for a repository.
PS: I think Corporal was talking about Mercurial
Brian Clozel
2008-10-01 22:24:56
Maybe I grew up on CVS and learned to take advantage of things that it can do that svn can't which is why I find it lacking. For example, I have a working directory that all my build scripts etc. work with, and I want to back out (update via tag) a change in one file and rebuild. CVS can, SVN can't.
stu
2008-10-04 18:26:12
+20
A:
I originally added this as a comment to someone else's answer, but then realized that it was an answer, of sorts. I have done these sorts of transitions before, where there was no existing way to convert from one SCM system to another.
It's not rocket science to write a script that takes the list of commits from your SVN repository, and iterates through them one at a time, merging them into a newly-created CVS repository. Getting all the branches and tags exactly correct might be a bit more work, but if you want to just save revision history for a few branches, it should be pretty easy.
I'm also of the opinion that you won't really gain anything by switching back to CVS, but if you want to do so, then you'll likely be writing your own script. The "svn export" command will undoubtedly be useful in this endeavor.
Mark Bessey
2008-10-01 22:35:13
+1
A:
the only 2 drawbacks of subversion I can think of users coming from CVS are
- the speed of checkouts over http(s)
- the lack of modulaliases
the first one can be solved by using svn(+ssh) which is the more comparable format as CVS uses its own protocol as well. the second one is a little trickier, but can be emulated by svn:externals (which have their own nasty sideeffects) If you encountered any other additional drawbacks, I am all ear..
Peter Parker
2008-10-02 07:25:06
+3
A:
svn was supposed to be better than cvs but in some areas that didn't work well. The other distributed tools are a lot faster (svn is slow as hell, even cvs can be faster sometimes), have much more useful features than svn, are developing rapidly (while seeing any new feature in svn takes YEARS). On the other hand svn is quite easy to learn and centralized (this is important for some people).
svn team is focused on own agenda, it's very hard to get support from developers (comparing to other open source projects), some bug reports exists for long time without any interest from developers.
I'm disapointed by how svn project looks and how it's developed but well, maybe that will change in future.
xyz
2008-10-02 07:33:55
I appreciate a response from somebody that isn't 'you're an idiot because you're trying to do something that isn't popular.' Thank you. +1
stu
2008-10-03 12:52:58
A:
Just pay attention to one point: Bazzar, Mercurial etc. (who were advised by some people here) are all distributed version control systems. I found it almost impossible to manage big groups of programmers working on the same source code using these kind of tools. In my company we use SVN and it's doing a wonderful job.
Zamel
2008-10-02 07:51:10
Could you explain a bit more what your experiences are? Sun chose Mercurial for being usable for big groups of programmers, so it is very valuable what you have found.
Thorbjørn Ravn Andersen
2009-08-19 09:48:19
From my experience, it is best to update/merge/resolve conflicts as often as you can (at least once a day), especially in near deadline projects. IMHO, distributed systems encourage you to "work on your own".
Zamel
2009-08-25 09:46:21
+4
A:
One aspect of git has not been discussed when it has been brought to your attention in all these other answers: git provides a cvs server emulation, so that you might migrate to git (svn to git is easy and well supported) and later use a cvs server interface for accessing the repository in a centralized manner. Nobody has to know you use git in the background and you don't have to deal with distributed backup issues.
Olaf
2008-10-02 08:05:32
A:
No idea why you'd want to do this, but going from SVN -> GIT -> CVS might work
You'd run..
git svn clone http://thesvnserver ourrepo
Then using the following guide to export back to CVS (not entirely sure this will work):
http://issaris.blogspot.com/2005/11/cvs-to-git-and-back.html
git cvsexportcommit 4a20cbafdf25a141b31a8333284a332d1a4d6072
There's also git cvsserver
dbr
2010-04-14 22:57:23