views:

50

answers:

3

I am using Subversion and Subclipse for my source control and follow the process of having a main trunk and taking branches for versions.

This works well and there are no major problems merging. However when there are significant changes to a file both in the trunk and the branch (unfortunately necessary) I have to manually edit the conflicts. The problem is that I am finding that I occasionally miss a bugfix or two.

How do others handle this situation? Aside from paying more attention or employing someone with better eyesight; are there any other possible solutions?

I add my JIRA references to any commits, however these then get lost in the merge.

Thanks.

+1  A: 

Automated Unit testing & Continuous Integration ...

Jim T
The question is how to avoid missing bugfixes in merging. This looks like a good technique to me.
David Thornley
I suppose so, but that only finds them after they are missed - it does not address how not to miss them in the merge.
Tim
True - decent unit testing would cover a lot of this, however that's another issue.
Damo
+3  A: 

Make ALL changes to trunk and then cherry pick which revisions go to which version branch ... This gives you a visual record of what revisions have gone where (merginfo).

Also assumes that all revisions will be eventually be included in a release from trunk.

Jim T
+1 - that sounds like a good solution and one I have seen used successfully in the past.
Tim
I think mergeinfo is the way to go. I should be able to pull out a list of revisions from the trunk and compare. Will be interested to see if this works with manually editing conflicts.
Damo
A: 

If the problem is that you can't remember which bugfixes have been merged across from one day to the other, I'd suggest doing a "record merge only" using tortoisesvn - this is for exactly the situation where you've had to do things manually and now want to make a record of the fact.

Jim T
Do you mean using the "--record-only" flag?
Damo
that'd be the one ;)
Jim T