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
Git to svn
Can I migrate from GIT to SVN ? I didn't find any good procedure on the web.
Re: Git to svn
http://lmgtfy.com/?q=git+to+svn 2013/6/3 EricD > Can I migrate from GIT to SVN ? > > I didn't find any good procedure on the web. > -- Dominik Psenner ## OpenPGP Key Signature # # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ##
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,
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 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
Re: authentication error after upgrading client to svn1.8.0-rc2 (accessing a svn1.7.8 server)
On 05/31/2013 02:26 PM, C. Michael Pilato wrote: > Filed an issue for this in the Serf tracker: > > https://code.google.com/p/serf/issues/detail?id=102 Just to follow up on this: the Serf devs have fixed the problem, and the fix will be included in Serf 1.2.1 (which should be released in the next couple of days). Thanks so much for your bug report!! -- C. Michael Pilato CollabNet <> www.collab.net <> Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
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
How to use SVN to setup CIMS
Dears, I want to set up a cims by SVN. The system need to do a series test before commit. The changes can be committed until the test passed. The question is that the test machine is not the svn client the same as the code committed, I want to know how can I get the changes before commit by the test machine. I found a way may be solve this question: by the svn client hook, but it is not good way. I want to do this on svn server side. I need a function like p4 shelve. Can you give me some suggestion, thank. If there is any puzzled, please let me know. By LiberalJin
Re: How to use SVN to setup CIMS
On Jun 3, 2013, at 21:46, liberal...@viatech.com.cn wrote: > I want to set up a cims by SVN. I don't know what "cims" is, but… > The system need to do a series test before commit. This has been recently discussed, and the consensus was "don't do that", because there's no way for you to obtain a consistent state of the repository to test until the commit has been finalized. http://svn.haxx.se/users/archive-2013-05/0261.shtml Instead, use a continuous integration system that tests your build after each commit, and reports build failures (e.g. to a group email list) so that whoever committed a bad revision will know about it and can fix it quickly.
