Slashdot Mirror
Converting from CVS to Subversion?
Bob Bobbinson asks: "I'm currently looking to convert my workplace's CVS repository over to Subversion. The main issue I'm having at the moment before I can commence a roll-out is how we are currently using tags, and sticky tags. The project is a website and we have two tags which are used to put changes from the main trunk live (internally, and externally). All development is committed to the main branch, and when we want a change to go live we move the two 'live' tags to that current version. The live servers are both sticky tagged to these tags, so when we run an update on these servers they will only update to the version that the 'live' tags refer to. Currently I haven't found a satisfactory way to replicate this in Subversion, as moving tags, and updating on separate servers seems to be quite kludgy i.e. need to remove current tagged version from tag, then copy from the main branch over to the tag, then update this on the live server. So I'm trying to look for an alternative way to implement this staggered releasing of code live, and maintaining the ability to see what versions of files constitute what is live. Any ideas?"
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.
I assume you have a staging environment which would pull from the latest main-branch build.. It's easy to see what checkin version staging is using..
Once you have staging in an acceptible state ready for deployment, simply take the associated checkin-number (this SHOULD be a manual process) and post that to production.
In other words, ditch the remapping of tags as you used in CVS. This is an error prone process which destroys history.
In our development environment, we have a wiki that we (manually) update whenever we post things, and each deployment (to test, stage, production instanceX) has an associated svn checkin number.
If there is some memorable tag that we need, we svn cp a tag.. And obviously long-term modifications get their own branches.
While I'm not as happy with SVN's lack of relocatable tags, I do really like the idea that when using svn + fsfs as a backend, you have read-only back-versions. You can see everything associated with the checkin-number. CVS, on the other hand only lets you see the current state of the rcs files.. Sure there's a lot of history in there, but there is no associated "undo".. Yout have to use the cvs tools, and then you have to keep your fingers crossed that you're doing it right.
-Michael
First of all, Subversion has no tags. They might call them "tags" but they are really just branches. I consider this a bit of a flaw but whatever.
What you need to do is either
1) remember the revision number of the repository which has the "good" code. Write it on a stick note or something. This is as close to a "tag" as you'll get. Then just tell your build process "revision #123124 is the one to use".
or
2) use a separate stable branch, and ONLY merge known working code to this branch.
I used to think #2 was almost impossible in Subversion (no tags!) but then I discovered svnmerge. See if you can find it, I can't find it anywhere in my FreeBSD or Gentoo installs and I had to download it separately. But it's a godsend! It's even *easier* than using floating tags in CVS to keep track of merge points.
Basically svnmerge will remember which revisions (specifically, which diffs between pairs of revisions) have been applied to a branch, by storing the information in properties. I have a big project with multiple long-lived branches (one for each client), and I could not figure out how to do this in Subversion until I discovered svnmerge.
In CVS it's easy ("easy" meaning, I can write down a set of instructions that can be mindlessly followed to get the right results), just create a floating tag that represents the last point you merged from. One on each branch for two-way merges.
svnmerge makes this easy in subversion too.
(It would be even *easier* if Subversion tracked changesets instead of tree revisions but that's a rant for another day.. Darcs is looking promising though).
Subversion doesn't support "tagging" like you call it. There are constant of posts the subversion mailing lists about this. 90% of them are ignored, and a few get responses. They prefer to use their branching concept.
This is a case where the authors of Subversion are trying to force their philosphy of how to use version control on the users. I understand that: It is nice when your users are using the software the way that yoy think is best. But that isn't always possible, and they've removed a feature that is common to 90% of all source control systems.
That makes it very hard to migrate to Subversion. There are many build tools, developer's brains, and business procedures that depend on the concept of tagging. Their arguments against it only take into account one side of things. And unfortunately, it has become more of a holy war with the developers ignoring legitimate reasons to support it rather than address them. I really hope this changes, or I fear Subversion will never gain the "critical mass" that CVS has.
With that complaint out of the way, you can somewhat do what you want with two ways. One is to use a branch instead of a tag, and have some way to identify which branch is the "live" branch. A text file. A custom field on one of the files. A rule like "live-###" where you take the largest number. These are your best bet.
If you use a system where you have a large hierarchy, and you cannot deal with all those branches showing up on the tree (it can get really messy) than you can delete old branches, or move them elsewhere. If that's not possible, you are SOL, and Subversion won't work for you.