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?"
Re:use the check-in numbers (Score:3, Insightful)
Whoa there cowboy. There will be many cases where this isn't always practical.
For example, lets pretend you have a programmer working on the application code, and a designer working on the layout of a program. In this case, there is going to be a point where one person checks in their changes, which leaves the main branch in a broken state until the second person checks in their code.
You could solve this problem by creating an interim branch, and then checking that branch into main; but that adds alot of work to what is otherwise a simple, fast process.
Do you have any other suggestions for this situation. I'd be willing to bet this is the case for close to 50% of code checkins.
Re:CVS was designed for text files... (Score:4, Insightful)
Because there are a ton of features in CVS which are broken? Moving directories, versioning metadata & permissions; etc.
I'm not really into SVN's versioning system either. I suppose I could get used to it, but I still like the flexibility of CVS tags. But there are many compelling reasons to move from CVS to SVN.
Re:use branches, OR revision numbers (Score:2, Insightful)
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".
Ah, you don't get it -- to "tag" a release, you simply copy the head to your "tag." You can even mark the tag as read-only. Then you tell the production people to check out the tag. It's really simple.