subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Baumanis <gbauma...@cogstate.com>
Subject RE: Merging change sets for a production release,
Date Mon, 03 Jun 2013 18:26:30 GMT
Hi Andrew,
Thanks for your response.

I do everything but for the chaining of the revisions to merge in the same command.
I tried it once (granted a long time ago) and it caused such an issue for me  that after about
6 hours of swearing, I finally gave up and reverted the changes and did the merges one by
one.
At the time one by one allowed for individual merge conflicts - which made life a little easier.

As for the other ideas, we do already only merge changes from trunk that are complete and
have been given the appropriate release milestone.
Our release process is already issue-based.

Perhaps simply chaining the merge revisions is the answer?



> -----Original Message-----
> From: Andrew Reedick [mailto:Andrew.Reedick@cbeyond.net]
> Sent: Tuesday, 4 June 2013 00:48
> To: Gavin Baumanis; users@subversion.apache.org
> Subject: RE: Merging change sets for a production release,
> 
> 
> 
> > -----Original Message-----
> > From: Gavin Baumanis [mailto:gbaumanis@cogstate.com]
> > Sent: Monday, June 03, 2013 12:31 AM
> > To: users@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.
> 


Mime
View raw message