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?
13 回答
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.
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.
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.
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.
If you need something other than SVN for whatever reason, look at other version control systems. There are many, and they are almost all better than CVS (in fact, only Visual Source Safe is as poor).
SVN is not great. SVN is better than CVS. If you want to change checkout Mercurial, GIT, Bazaar.
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.
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)?
when all you have is hammer, everything looks like a nail.
best bet is to learn svn it will make more knowledgeable.
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
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.
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..
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.
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