Converting from CVS to Subversion? 62
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?"
use the check-in numbers (Score:5, Interesting)
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.
Just stop thinking in terms of "sticky" tags... (Score:4, Interesting)
In the subversion philosophy of doing things, ideally a tag shouldn't ever get changed. A tag should be pretty much a snapshot in time that stays as it is forever.
For instance, here's an example of branching/tagging the way subversion thinks of it (although you are free to twist it to other methods):
I have my main trunk, which lines in "trunk/..." in my repository. The trunk is at version 31666 right now. I decide that rev 31453 (the last good stable build from 2 days ago before I started mucking with a new feature) will be the branching point for my 1.0 stable branch. So I issue an "svn copy" command to copy rev 31453 of the turnk directory to a new place in the repository called "branches/1.x-stable". I tell the team that that branch is in feature freeze - debug it. They find a few bugs, which they commit to either the branches/1.x-stable tree, or the main trunk, and in either case they also copy their change to the other if it's applicable.
After a few weeks of debugging like this, I decide that at repository revision 31942, the "branches/1.x-stable" branch is stable enough to release the real 1.0. So I issue an "svn copy" command to copy rev 31942 of "branches/1.x-stable" to "tags/1.0". I never update this tree in tags/1.0 again. It essentially serves as a permanent record of what we released as 1.0, and a convenient spot to pull the 1.0 release from for packaging (or for comparison down the road).
After giving 1.0 to users, based on user feedback 3 new bugs were found in the 1.0 release. The coders fix these in the "branches/1.x-stable" tree, and reflect those changes back to the trunk if they're applicable (trunk may no longer have the affected code for all we know at this point). We decide that the 3 bugs were serious enough to warrant a 1.1 release to customers, so we make yet another "svn copy" off of "branches/1.x-stable", after the 3 fixes are in, as "tags/1.1", and release that copy as 1.1.
etc...etc...
To apply things to your situation (where you seem to essentially be using tagging but no branching, which is something you may wish to rethink down the line), essentially what you would do is every time you want to publish a "stable" copy internally or externally, you would just make a brand new tag. Instead of "updating" a tag named "internal" or "external" with your new code, you would create a new tag named "internal-1.1.2" or whatever you choose to version it as - but never change old tags, just make new ones.
Once you've done "svn copy" to make your new internal or external release tag, then you go to the actual webserver where you want to check it out, and in place of your previous "cvs update" on a checkout of a sticky "external" tag, you instead do an "svn switch" command from "tags/external-1.1.1" to "tags/external-1.1.2", which will alter the working copy as minimally as neccesary to switch you over to the new tag.
Re:Just stop thinking in terms of "sticky" tags... (Score:3, Interesting)
do though.
The poster wants, I believe, to have a 'live'
release, so that some 'get the current "live"'
will always get the code considered to be
released. For example, by a cron-job doing
an update at 3:47 AM each night.
This kind of thing is not really amenable to doing an 'svn switch', which requires knowing whether or not things have changed and what the new version is called.
Perhaps the correct answer is 'write a more complex cron job that detects whether there is
a tag 'live-.*' where
than the current version.'
Or perhaps the correct answer is to use a branch.
Or perhaps something else that a subversion user
would know.
(I'm not, and don't know, the original poster -
but having worked with CVS as web-site tracker
and CVS as compiled-code tracker... the poster
sounds like he's doing something much more like
the former... )
use branches, OR revision numbers (Score:4, Interesting)
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).
Re:If I understand correctly, you want... (Score:3, Interesting)
It's very worth it in terms of how much easier it is to sync with the latest bugfixes in your live branch.