Version Control - release strategies

From:	Peter (BOUGHTONP)	21 Jul 2007 14:31
To:	ALL	1 of 7

32877.1
Does anyone here use version control software for managing structured code release? (eg: multiple dev versions, one or more testing/staging versions, then the live version) At work we're trying to figure out the best way to handle things. We've got six developers working on the same four projects doing tasks of vastly varying complexity/duration/criticality, and we need to ensure that we don't put live untested code, nor hold up the deployment of bug fixes and critical features. Currently the strategy is to use a different branch per task, then when completed our tester tests the branch, and either throws it back to us, or it gets merged into the HEAD trunk and deployed to live. However, this can cause problems when we get changes to the core files (eg: to fix a bug), because people already branched don't get it. And branching all the time is annoyingly slow. Etc. Anyway, we've now got a Director for our department, and he wants to have a meeting soon discussing how to proceed with it, and I'd like to be able to walk in and say "everyone shut-up and listen to how we're going to do it..." Surely it can't be a hard thing to do - source control has been around for ages, and people must have been able to come up with a sensible dev/stage/live methodology by now? `3.1415P265E589T932E846R64338`

0/0

Reply Quote

More

From:	Ben (BENLUMLEY)	23 Jul 2007 00:02
To:	Peter (BOUGHTONP)	2 of 7

32877.2 In reply to 32877.1

i occasionally get the same problem with bug fixes missing from the branches, when I'm mostly the only person working on the code.

I use SVN, and find the only way I can really get round it is to merge the trunk with the branches. But that too is time consuming.

And SVN has no automated way to record when merges were made (its planned to be added at some point from what i read), so you have to read back through the commit messages to find when the last merge was ... etc.

SIGSIZESWITCHER

0/0

Reply Quote

More

From:	DSLPete (THE_TGG)	23 Jul 2007 08:06
To:	Ben (BENLUMLEY)	3 of 7

32877.3 In reply to 32877.2

svn can and does do merge control, you just have to take a note of version numbers (boring). However, we use svk which is a wrapper on top of svn, and it is extremely useful. It allows you to do stuff like this:

Trunk: /local/trunk
Branch1: /local/branches/branch1
Branch2: /local/branches/branch2

Person 1 is working on Branch1 and decides to roll what they have done so far to trunk. They issue the command:

code:

svk push -l

This merges branch1 with trunk, in essence 'pushing' the branch back into its parent. The -l switch tells svn to lump all the changes together. If you omit the -l it will commit incremental changesets, depending on the number of pulls that have been done on the branch (see below to read about pulls)

You can even do:

code:

svk push -lC

which is a pretend push, so you can sanity check all the changes.

The even more cool bit comes when the person working on branch2 comes to work on it. They simply issue:

code:

svk pull

which pulls all changes from the parent branch (in this case trunk) into your branch (in this case branch2). So all of the changes made on branch1 are now pulled into branch2. Awesome!

where I work, there can typically be up to 20 projects on the go at any one time, each with its own branch. This system works remarkably well, you can even merge branches with branches and branch from a branch (which I frequently do). As a rule of thumb everyone working on a branch will do an svk pull every morning, first thing. This keeps everyone up to date and conflict free.

Also, consider the scenario where two projects are being worked on, both of which are heavily dependent on each other whilst at the same time being developed on separate branches.... it makes sense to test the two together, which you can do with svk by simply creating a third 'test' branch and 'smerging' the two development branches into the test branch, which is then typically deployed onto the QA platform. It really does open up a whole new world of flexibility.

I also believe subversion 1.5 will have similar abilities (so you can do away with the svk wrapper) when that is released.

0/0

Reply Quote

More

From:	Ben (BENLUMLEY)	23 Jul 2007 08:30
To:	DSLPete (THE_TGG)	4 of 7

32877.4 In reply to 32877.3

mmm.... that looks very nice. I shall read about that and maybe give it a go.

And yes, as I say, SVN does the merge stuff yes, but remembering the numbers is what I meant when I said you have to flick through commit logs. Getting changes from the trunk into a branch becomes time consuming enough that it isn't done as often as it should be.

SIGSIZESWITCHER

0/0

Reply Quote

More

From:	Ben (BENLUMLEY)	23 Jul 2007 08:43
To:	DSLPete (THE_TGG)	5 of 7

32877.5 In reply to 32877.3

Been thinking about that, and from what you've said, it adds the things that I was saying (meaning to say) were lacking in svn.

What about clients though? From what I can see, they are all command line based. I could live with that, although browsing the history and writing log messages becomes a bit fiddly (from my experience with svn).

But I can't see the other folks where I work dropping tortoisesvn for a command line when they barely use branches. Half the time they don't even bother with SVN at all.

SIGSIZESWITCHER

0/0

Reply Quote

More

From:	DSLPete (THE_TGG)	23 Jul 2007 09:18
To:	Ben (BENLUMLEY)	6 of 7

32877.6 In reply to 32877.5
Ha. You need discipline in your ranks :) We wrote a tiny python app which provides a GUI for those who can't cope with the command line. You should also check out trac if you've not already. It's version control integration is lurvely. Visual, clickable changesets, source viewing at any revision you want etc etc. It's the future.

0/0

Reply Quote

More

From:	Ben (BENLUMLEY)	23 Jul 2007 09:45
To:	DSLPete (THE_TGG)	7 of 7

32877.7 In reply to 32877.6

I am already familiar with the joys of trac, yes. I like it lots, particularly the ticketing and updating/closing of tickets with time taken directly from svn commit messages.

Presumably it still works fine with repo's used with SVK?

But I prefer the "show log" and "repo browser" on tortoise svn. Trac would do fine if i didn't have the tortoise ones though.

SIGSIZESWITCHER

0/0

Reply Quote

More