Version Control - Advice needed

[Taxious]

So your using the Windows recycle bin to store your source code and manage your projects

I usually have a mess of files in recycle bin and a "temp" folder on my desktop I put stuff into, but still <3 SVN <3

As long as management understands that they're wasting a certain amount of development effort (which it sounds they probably do) then I guess there's not much to be done other than to optimize subversion.

Yeah I just got out of a meeting where we were discussing this. Management definitely understand the burden/mess this is creating and my boss was actually just talking about giving me some time in the future to come up with some solution to make the process cleaner. Hrm..

[Freecare Spiritwise]

One thing I would be thinking of is minimizing the dependencies that team B has on Team A's code. There's a lot of ways to create those abstractions - services, generic interfaces, full blown abstraction layers, etc.

So reduce your dependencies and maybe put team A on team B's release cycle, which I'm sure team A wouldn't like. I do think that putting both teams in sync would reduce that wasted effort all things considered. And again, I don't much like those longer cycles. Team A goes off on some tangent and it's 3 weeks before you figure it out.

[Ddrak]

One thing that concerns me though: This global revision counter. It's going to get huge isn't it? Y'all must have some big counters. I picture someday looking at revision 769876978698769867968769 and it just seems kinda weird. Oh well.

We're at 170,000-ish and tick over about 100-300 per day depending on how busy we are. Never really been a problem.

How would you guys handle this situation?

- About 6 developers (team A) are working on the trunk of a project which releases every 3 weeks.
- A couple other developers (team B) are working on branches of the truck which release ever 1 week.

A new branch is created from the trunk when (A) releases so that (B) can work on that to update their code and release every week until (A) releases again. When (A) releases again, the new trunk is created and all the changes from the new release must be merged in with the changes from the previous branch that (B) has been working on for the last week.

That's not going to work well in subversion. It really wants you to merge all the stuff from (B) back into the trunk before (A) makes their new branch. Merging from branch to branch is going to give pain. I've got 3 suggestions:

i) Stick with Subversion and use their recommended branching rules:

"Trunk" belongs to no one. (A) and (B) work in their own branches. Each team releases by:

• Merge changes from trunk into your own branch, fixing conflicts
• Reintegrate merging into trunk, checking everything works after the checkin
• Deleting their branch
• Creating a release "tag" branch
• Branching their branch from trunk fresh
• Notifying the other team to merge changes from trunk to make sure they are keeping up with the changes to avoid massive conflicts

That's basically how we work - we have a bunch of teams that each work in their own feature branch and do daily pulls from trunk to get whatever changes everyone else has committed. That way it's the teams responsibility to solve their own merge conflicts (because they're the ones best able to deal with it).


ii) Switch to git or mercurial. They handle merging a lot better but have the downside of a little more overhead in creating a central repository.

iii) Look into ClearCase (from IBM). It has the God of all merging solutions but requires a Ph.D. to understand it.

Dd

[Taxious]

I guess I fucked up the merge last week and I'm not really sure how. I had to merge the branch that people were working on the previous week (3.06) with the trunk. Then merge the trunk into the new branch (3.07) - and some files that were changed came through and others didn't, seemingly in no coherent pattern. I guess our "architect" guy is going to look at this process and come up with something new this week as this has been a big problem in the past as well.

That way it's the teams responsibility to solve their own merge conflicts (because they're the ones best able to deal with it).

Yeah that'd be nice, not sure why this isn't happening. They decided to make one person (me right now) responsible for all merging instead.

[Freecare Spiritwise]

It's been about 8 months and I'm still very satisfied with Subversion and its clients, especially Ankh. We have an offshore team in Manila and we've seen good results with Subversion over a slow VPN, which is where Source Safe was killing us. I just fricken love Ankh even though it can be a little tempermental.

So thanks again for the advice, and party on dudes.