> -----Original Message-----
> From: Gavin Baumanis [mailto:gbaumanis_at_cogstate.com]
> Sent: Monday, June 03, 2013 12:31 AM
> To: users_at_subversion.apache.org
> Subject: Merging change sets for a production release,
> Importance: High
>
> At the moment we do all of our work on /trunk and also have
> /branches/releases/1.0 When we have enough issues, we mark the ready /
> required issues with a new release milestone and I go about the task of
> merging the required changes from trunk to the release branch.
Is there a reason why you all are not doing Release Planning ahead of time?
> Here is what I am currently doing, that is giving me some issues, and I
> am hoping someone might be able to see what I am doing wrong / have
> some advice / comments to better the process I am using.
>
> Let's assume that I have multiple completed issues ready to merge from
> trunk that will become the "Changes" from the last version.
> Let's also assume that I have multiple subversion commits per issue -
> sometimes ~20 commits can be assigned against an issue.
> Let's also assume that the very same files that have the required
> changes to go to the new release - have other, not-ready for release
> changes made to them too.
>
> The scenario seems pretty ordinary to me - but I could, of course, be
> completely wrong.
>
> Anyway,
> So I open the first issue, notice there are 3 commits assigned to this
> issue.
> The first commit has 3 files,
> I do a cherry pick merge from trunk for each of the individual files
> listed in the issue.
>
> (Ignoring the paths...)
> svn merge -c 1234 /trunk/myPath/myFile1.c
> /branches/release/myPath/myFile1.c
> svn merge -c 1234 /trunk/myPath/myFile2.c
> /branches/release/myPath/myFile2.c
> svn merge -c 1234 /trunk/myPath/myFile3.c
> /branches/release/myPath/myFile3.c
>
> I manually resolve any conflicts that I may have.
>
> I then open the 2nd issue and repeat the process above as required for
> the change sets listed in the 2nd issue.
Is each svn commit tied to an issue? Meaning, are all the changes in a single revision tied to an issue?
You shouldn't need to merge individual files. Just do a 'svn merge -c 100,110,...,N svn_url' and let svn walk through the cherry-picked merges.
>
> A "problem" I am having is that I tend to get a lot of Merge conflicts
> doing it this way.
>
> But my biggest problem and the purpose for this email is; I might have
> a quite a few helpdesk issues to create a new release from.
> The same file might be edited in numerous issues.
> I often find myself doing a merge of a revision number less than one I
> have already performed.
> (depending on the order that I do the issue merging, of course)
>
> And "oddly" to me - I find at times when this is the case that my
> initial merge to the release branch is negated / overwritten.
>
> I am certain that it is a usage issue - but short of somehow ensuring
> that I do all the required merges in order - which is simply just too
> difficult to achieve - I find myself constantly battling with ensuring
> that the release branch is updated with all that this is necessary.
>
> If anyone has any ideas I would be most grateful.
Change your process.
Brick Wall Analogy:
Imagine that trunk is a brick wall built with 100 bricks (issues.) You're only merging 80 bricks (completed issues) to the release branch. The 20 missing bricks can result in gaps in your wall that are structurally unsound, or could even result in bricks floating in mid-air due to dependency issues (supporting bricks/issues were not merged over.) It's a crazy, slow, and stressful way to build a wall.
IMO, you have several problems:
1) A lack of release planning. You all don't decide on what's going into a release until after the work is done. Which means you don't take dependencies into account. You don't take development time into account which can result in continual merge conflicts since you are always having to skip over commits related to the long running work-in-progress issue. You wind up mixing an inordinate amount of complete and incomplete code together which dramatically increases the number of merge conflicts. And so on. Doing "release planning" at the end of the cycle ends up requiring more work (i.e. conflicts, merge headaches, a very slow release process) and can require pulling in dev resources to resolve merge issues (which interrupts their current work, and requires them to look at code that's no longer fresh in their mind, which is a very inefficient way to work.)
In other words, "prior planning prevents poor performance." Decide what's going into a particular release instead of using /trunk as a dumping ground for random changes, especially when those changes have dependencies (aka merge conflicts.) You'll probably want to triage your issues and assign them to a branch (e.g. "fixVersion" in JIRA.) Then use a pre-commit hook to reject check-ins unless the issue's "fixVersion" matches the branch. Meaning, don't allow 1.1 work to be checked into the 1.0 branch.
2) You probably need to use feature branches. If you work each issue (or related issues) on their own branch, then merging (or unmerging) the completed issues into a release branch should be easier. You'll still have merge conflicts, but they should be fewer and easier to manage/research/understand. You'll probably also want to merge completed feature branches to an integration branch before cutting a release branch.
3) As mentioned previously, you shouldn't be merging individual files. Let svn's merge tools do the work for you: 'svn merge -c 100,110,...,N svn_url' Not following svn's merge paradigm is just asking for unnecessary work and pain.
Received on 2013-06-03 16:49:55 CEST