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?"
KDE (Score:5, Informative)
--
Evan
If I understand correctly, you want... (Score:4, Informative)
svn commit
When
svn rm repos/livetag
svn cp repos/trunk repos/livetag
Then, on the live servers:
svn update (where they have working copies of repos/livetag)
OR, you could do:
svn cp repos/trunk repos/tag-20050403
(i.e. create a unique tag for each release)
then, on the live machines do:
svn switch repos/tag-20050403
Either way should do the trick. And as other posters have pointed out, have you asked this question on the Subversion mailing list?
svn:externals? (Score:3, Informative)
Couldn't you use svn:externals to do what you want? I mean, couldn't you have a 'live' project or something that simply listed whatever tag you wanted in your externals? Then, whenever you get the 'live' site, it would get whichever tag was currently referenced?
Instructions are at http://svnbook.red-bean.com/en/1.0/ch07s03.html [red-bean.com]
Re:Just stop thinking in terms of "sticky" tags... (Score:3, Informative)
myproj/trunk/[...]
myproj/tags/external-1.1/[.
myproj/tags/external-1.2/[...]
myproj/extern
Where the tags work as I outlined, and "myproj/external-release" is a text file which is manually updated to read "1.1" or "1.2" or whatever.
Then the cronjob on the production server essentially does
svn checkout svn://mysvnsvr/myproj/external-release
svn switch svn://mysvnsvr/myproj/tags/external-`cat
Or what-have-you for the specifics.
Subversion software -vs philosphy (Score:5, Informative)
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.
Re:use the check-in numbers (Score:4, Informative)
On your projects, perhaps. On mine, never. I use continuous integration tools like Anthill [urbancode.com] and Cruise Control [sourceforge.net], and anytime a checkin breaks the build, the developers hear about it pronto. This is a little annoying to start, but once you get broken in it's fabulous: what's in CVS is always trustworthy, and if you see a problem you know it's your problem.
If you're just using CVS to pass around files, then you could just email the files around. If you keep the units of work small, clear, and discreet, this works fine.
Another option is to have areas in CVS for things that are half finished; the person to do the last bit of work moves things to their proper place.
With the designer/programmer split, one helpful approach is to make the last step connecting it to the rest of the app. So if it's a web app, you put up the new pages in a way where you can get to them only if you know the URLs. Then only when they're perfect do you add links from other pages.
You can also make features configurable, so that a feature is only visible if certain configuration options are set. This is especially valuable in environments where you have to roll out multiple related servers but need to bring everything live at the same time.
But my favorite approach is to get the necessary people together in one place. E.g., the programmer pairs with the designer, and you get things done in one go. Not only is it faster and more likely to work, but both sides learn a lot more about how the other guy works.
Re:If I understand correctly, you want... (Score:2, Informative)