The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Subversion and tagging

Since there are so many Subversion advocates here, I thought I would ask on this forum. I'm thinking of switching from CVS to SVN, but I'm not sure how it will affect our release process.

Our company makes web sites, and we don't have "builds" of the entire site; we make changes to certain files, and release those files to QA and then production. Currently, we tag a file when it's ready to be released to QA (or production). Then we have a script that copies those tagged files over onto the QA or production branches. Before it does, it tags the latest version on the QA/Prod branch, so we can roll back to that version of necessary.

Since SVN has a different model of tagging, I'm not sure how we would migrate this system. Basically we want to maintain a history of the changes to QA and production, and be able to roll back to certain versions.

Could anyone point me in the right direction? Thanks.
JW
Tuesday, December 12, 2006
 
 
Unlike CVS, SVN makes a new revision number for *whole repository* at each check-in. This means that you don't need to tag your files to include them in a certain build; instead, you just invoke revision #16434.

To make things easier, SVN allows for a tagging concept which essentially consists of applying names to specific reviosion numbers. So you can revert to "version 1.45" which is actually your revision #16434.
Berislav Lopac Send private email
Tuesday, December 12, 2006
 
 
SVN tagging is extremely easy and intuitive. Read the SVN book that comes with SVN to see some examples of how to use it.
sloop
Tuesday, December 12, 2006
 
 
> Could anyone point me in the right direction?

Sync the entire tree and let your publishing software determine what files have changed and need copying. No more tags.
son of parnas
Tuesday, December 12, 2006
 
 
The problem is that we don't want to release all files that have changed. And we don't always want to release the head revision - in some cases we want to release an earlier revision. So I don't think we can just refer to "revision #123" and move the whole thing to production.

In CVS we could tag a particular set of revisions and move just those tagged files. But with SVN, it seems like a tag would have to encompass the entire project. Even though they're not hard copies, this doesn't sound like what we want.

But I will look at the Subversion book and see if it helps.
JW
Tuesday, December 12, 2006
 
 
Please respond here with what you find.  I've been using SVN for a while now after having used SourceSafe, but I've been stuck with the same issue: I want to check files in, but not tag them as 'release ready'--haven't figured out a good way to do that.

I'm _guessing_ the way you do it is work in a separate  (personal) branch, and then when it is release ready you merge it to the release branch.

Do others agree that this is the way to do it?
Doug
Tuesday, December 12, 2006
 
 
"So I don't think we can just refer to "revision #123" and move the whole thing to production."

Why not?  What you'll want to do though is make a new branch/tag for that revision so you can give it a friendly name.

Even better though might be to have Development, QA, and Production branches and just merge the changes from one to the other as necessary.

"Even though they're not hard copies, this doesn't sound like what we want."

Subversion replaces all the CVS concepts with copying and merging.  It can take a little while to figure out how to get that to work with your existing processes but the final result is something that is actually much simpler.

--

"I'm _guessing_ the way you do it is work in a separate  (personal) branch, and then when it is release ready you merge it to the release branch."

That's what I do.
Almost H. Anonymous Send private email
Tuesday, December 12, 2006
 
 
> The problem is that we don't want to release all files that have changed

As mentioned, use a branch. It's much simpler and far less error prone then everyone trying to manage which files should be released.
son of parnas
Wednesday, December 13, 2006
 
 
Having the separate branches is definately the way to go. You could even go so far as to have each dev on a private branch, but you get a lot of overhead when you all need to merge back to the trunk.

Having said that, there is a way to add CVS style tags to files and revisions. Take a look at Properties - the svn propset etc. commands. You can add a property to a file or a particular revision to mark it with whatever metadata you want.

But the branch structure will work out much, much better.
Chris Tavares Send private email
Wednesday, December 13, 2006
 
 
> Having the separate branches is definately the way to go.

I don't quite understand what you (and others) mean by this. We already have separate branches for QA and production. (I'd rather not have a separate branch for each developer, to avoid merging headaches.) If I want to be able to indicate certain files/revisions which should be moved to QA, but not others, I would need to create a completely separate branch for that? This happens several times a week, so that sounds like it would become unmanageable.

I've looked at the Properties, which seem like a possibility, although I take it that SVN people wouldn't advocate their use as tags.
JW
Wednesday, December 13, 2006
 
 
sheesh, amateur hour around here.

Have one branch that devs submit into.
Have another branch that your released product is built out of.
At intervals integrate changes from the development branch into the release branch.
Have daily build and test processes that run on BOTH BRANCHES.
If you can't figure out how to do this with Subversion, go use PERFORCE.

We really need some sort of barrier to entry in the IT industry.
Monkey Fuel
Wednesday, December 13, 2006
 
 
> We really need some sort of barrier to entry in the IT industry.

My barrier would start with superior sounding snarky know-it-alls who hurt more than they help. It's through forums like this that people learn.
son of parnas
Wednesday, December 13, 2006
 
 
"If I want to be able to indicate certain files/revisions which should be moved to QA, but not others"

I'm not sure I fully understand what you mean by that.  I'm going to assume I understand and lets see how far I get.

You have QA and production branches.  You also have a HEAD branch.  What you likely need is one more branch, like a version xx branch that represents your next release.  This isn't the HEAD branch because that's where all the development goes.  Version xx is your "tag" for release to QA.  You merge changes into it from the HEAD (or do development on it directly) and when you're satisfied, you move it to QA.

I'm going to assume you aren't trying to tag individual files to be moved to QA separate from the project because I don't know why you'd do that.
Almost H. Anonymous Send private email
Wednesday, December 13, 2006
 
 
Reading over the Branching and Merging chapter of the Subversion book may provide ideas on how to to apply Subversion to your specific situation: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Not trying to pass the buck, but you understand your needs better than we do, and something may well click for you while reading the book.
Cory Grimster Send private email
Wednesday, December 13, 2006
 
 
AA: This is our process. We tag files with "move_to_qa" when they're ready to go to QA. Then we have a script that finds those tagged files/revisions, and copies them onto the QA branch. Since you tag a specific version of a file, it's possible for someone to commit a later version to development, and we would still pick up the right one.

What we do isn't really a merge, since we just replace whatever's currently in the QA branch. In fact, QA isn't used as a typical branch; it's just a history of the revisions that have been moved to QA.

What you're suggesting makes sense, and it's probably the closest parallel to what I'm doing now in CVS. But it seems like it would still require more manual merging than our current solution.

> I'm going to assume you aren't trying to tag individual
> files to be moved to QA separate from the project
> because I don't know why you'd do that.

Well, that's kind of what we do. But as I mentioned, it's a web site -- actually a bunch of them -- so we don't have traditional builds. We don't move the entire project to QA at once; we just move pieces that are ready.
JW
Wednesday, December 13, 2006
 
 
"What you're suggesting makes sense, and it's probably the closest parallel to what I'm doing now in CVS. But it seems like it would still require more manual merging than our current solution."

You should be able to setup a very similar process.  Create a QA branch and merge the changed files into that branch when you would currently have tagged file as move_to_qa.  Merging is subversion is much easier than in CVS.  Now the QA team just sucks down the QA branch when they want to test.

Another idea is to create tags for each version that goes to QA.  So you create a 'version xx' tag/branch and copy files into that branch that are ready to go.  Then QA just sucks down that specific version branch for testing.

"But as I mentioned, it's a web site -- actually a bunch of them -- so we don't have traditional builds. We don't move the entire project to QA at once; we just move pieces that are ready."

I use SVN on a bunch of websites as well.  I have a seperate project (which is really just another subdirectory in SVN) for each website.  That way they can be handled individually.  There are some common pieces implemented as externals (modules in CVS terminology).

Despite the surface similarities between Subversion and CVS, there are really very different.  You really do need to change your way of thinking when working with subversion -- don't try and fit a square peg (CVS processes) into a round hole (SVN processes).  All in all, I am far happier with subversion than CVS and I've done a lot more with it than I ever did with CVS.  I hope you can figure out a system that will work for you.
Almost H. Anonymous Send private email
Wednesday, December 13, 2006
 
 
I was in the same boat as you until I discovered svnmerge.  You'll find it in the ./contrib directory of the source files.

Get into the habit of checking things in as logical chunks instead of all the changes in one fell swoop.  In other words, each commit should have a comment like "improved template system" not "improved template system, fixed bug 12354, added new module for accounting". That way each "chunk" gets its own revision.  Make sense?

Once you do that, you can use svnmerge to pick and choose which revision numbers you want to push into your release branch.  You can push out "improved template system" (r1) and "new module for accounting" (r3) without merging r2, the bugfix.  Bam, no more need for tags and you can pick and choose what to push out.

They really ought make svnmerge more advertised; it is quite useful.  It truly takes the sting out of merging.  I'd also say it lets you really appreciate how svn tags the entire commit with a number instead of assigning separate version numbers per file.  The key is the change in habit.  Each checkin should be for a "concept" or chunk, not every thing you changed on your tree.
Cory R. King
Friday, December 15, 2006
 
 
By the way, everything you can do with svnmerge you can do with straight svn.  Svnmerge just makes:

[joe]$ svn merge <dont forget to decrement your revision number because <something>, dont forget to comment on revisions you merged or else you'll double merge, this command really does get this long and oh crap, which changes can I merge again?>

into:

[joe]$ svnmerge avail  # get the revisions I haven't merged yet

[joe]$ svnmerge -r2,5,7 -f commit.txt && svn ci -F commit.txt && rm -f commit.txt  # merge reversion 2,5 and 7 and use commit.txt for my comment.

Simple, refined and elegant.  Who needs CVS again?
Cory R. King
Friday, December 15, 2006
 
 
Before you switch to Subversion, mdo not forget to compare the performace of both systems on showing revision history. I had  performance problems with Subversion in my current project so I kept using CVS.
curious
Monday, December 18, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz