RE: Merging change sets for a production release,
Hi again - I have a follow up question, please. I had an helpdesk issue with 18 changesets attributed to it. It took a while to resolve all the issues - but I finally got there. I did a "diff" on one of the files and I noticed that in the revision that there was a conflict for that file - there was no mergeinfo recorded for that revision. Do I need to do a --record-only "post" merge when there is a conflict? As always - thanks, - Gavin. > -Original Message- > From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] > Sent: Tuesday, 4 June 2013 06:08 > To: Gavin Baumanis; users@subversion.apache.org > Subject: RE: Merging change sets for a production release, > > > > > -Original Message- > > From: Gavin Baumanis [mailto:gbauma...@cogstate.com] > > Sent: Monday, June 03, 2013 2:27 PM > > To: Andrew Reedick; users@subversion.apache.org > > Subject: RE: Merging change sets for a production release, > > > > 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? > > > > Yes, I would try the 'svn merge -c ...' "changed" merge again. > > Assuming you're using SVN 1.7, "chained" merges should be much easier. It > is still an iterative process, in that if a merge conflict is encountered, > svn will > prompt you for what to do, then you fix the code, resolve the conflict, and > re-run the merge command to pick up where it left off. You will probably > want to use 'svn merge --accept postpone ...' to avoid the prompting. It's > normally a good idea to save off your merge command so you can add it to > the commit comment (or in case anything happens to your command line's > history buffer.) >
Re: Merging change sets for a production release,
Guten Tag Gavin Baumanis, am Montag, 3. Juni 2013 um 20:26 schrieben Sie: > 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. This alone won't help you. How many merge conflicts you get depends on the differences between your release branch which you merge the issues from trunk to and how it differs from trunk. If you have something like a rolling trunk where development for all next milestones is done, not necessarily only those for the changes between release 1.0 and 1.1, the chance for merge conflicts rises of course. That's what, from my understanding, features branches based on release 1.0 or trunk about that point addresses or why projects with a rolling trunk branch the whole trunk and not only apply some changes to a release and stabilize it for some time. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Merging change sets for a production release,
> -Original Message- > From: Gavin Baumanis [mailto:gbauma...@cogstate.com] > Sent: Monday, June 03, 2013 2:27 PM > To: Andrew Reedick; users@subversion.apache.org > Subject: RE: Merging change sets for a production release, > > 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? > Yes, I would try the 'svn merge -c ...' "changed" merge again. Assuming you're using SVN 1.7, "chained" merges should be much easier. It is still an iterative process, in that if a merge conflict is encountered, svn will prompt you for what to do, then you fix the code, resolve the conflict, and re-run the merge command to pick up where it left off. You will probably want to use 'svn merge --accept postpone ...' to avoid the prompting. It's normally a good idea to save off your merge command so you can add it to the commit comment (or in case anything happens to your command line's history buffer.)
RE: Merging change sets for a production release,
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.reed...@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:gbauma...@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 resul
RE: Merging change sets for a production release,
> -Original Message- > From: Gavin Baumanis [mailto:gbauma...@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 bra
Re: Merging change sets for a production release,
On Jun 3, 2013 12:27 PM, "Gavin Baumanis" wrote: > > Hi Everyone, > > 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. > > 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. > > 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. > > - Gavin
