Re: Cherry-picking merges
bad idea, and should be discouraged. A revision that contains svn:mergeinfo changes should only contain the file and structure changes logically equivalent to the revisions that have been merged. Sure, but back to Joël's question: that still does not mean SVN can assume this merge changset never needs to be merged back and you shouldn't have to cherry-pick around it. Let's say we have source code or scripts in our repository. r10 changes a parameter to a function and adapts all callers. You merge r10 into a branch, but earlier in the branch you had added another call to the function. You need to fix the call before the merge is logically complete. You could still commit the raw merge first and the logical completion of the merge as a second changeset. In fact, that's what you would have to do to allow pristine cherry-picking from your branch back to the trunk. So let's make it a little tougher: both branches have changed a parameter of the same function. Merge conflicts all over. You want all the help you can get to resolve those conflicts. So you call on your compiler, test suite, whatever. It's next to impossible to separate this merge into a raw merge and changes due to interference of the merge and earlier changes in the branch. -- Stein
Re: Cherry-picking merges
Daniel Becroft djcbecr...@gmail.com writes: We've only just started using feature branches, and most of the time, our merges are one way (trunk - branch), until, eventually, we need to reintegrate (or just dump the branch). One the few occasions that a branch - trunk is required, we just do it manually. Less work for something that is fairly rare (for us). Agreed - if you delete the feature branch just after you reintegrate it, all is simple. A better fix would be to have commit C be marked as merge-from-source in some sort of commit property and to have merge to a branch omit changesets that are being merged back to that branch. This is exactly what the svn:mergeinfo property is for. But, the downside is that it records when rX from branchA was merged in rY of branchB. As below, it does not state that rY on branchB is the logical equivalent of rX. I at first thought not quite - svn:mergeinfo is modified in a commit to indicate which path and revisions have been merged in, so that those revisions can be omitted from a future whole-branch merge. I was looking for an explicit commit property, but I think you are right for at least the simple case. The idea would then be svn merge $URL will, for each revision between the common ancestor and the tip of URL, old behavior: merge that revision if it is not listed in svn:mergeinfo on the revision/path corresponding to the working copy new behavior: the same, except that commits on $URL are excluded if they add mergeinfo with a path corresponding to the working copy This only works if each commit is either a clean merge or something else, with no mixing. But this has to be carried along so when you merge from A to B to C and merge C back to A you don't redo the A commits. So the bookkeeping is hard, but I think that's what it takes. Implementing this might or might not be easier than training everyone how to use Git :-) See above. The merge to C will contain a modification to svn:mergeinfo that contains details of branch A and branch B. The problem is that the merge from A to B changes B, and then the merge From B to C will bring along changes that are B changes as well as the A changes, and you can't ignore the whole thing going back to A. pgpCKfutFIwFE.pgp Description: PGP signature
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 10:08 AM, Vadym Chepkov vchep...@gmail.com wrote: Hi, I know, this is maybe not the best practice, but, unfortunately, our subversion users do this all the time: they merge form one branch to another back and forward. The question is, how to properly do it without introducing conflicts. Here is the test case, which one would think should be handled properly, but for some reason it's not: [~]$ svnadmin create mergerepo [~]$ svn co file://`pwd`/mergerepo mergework Checked out revision 0. [mergework]$ svn mkdir --parents branches/b1 A /home/vvc/mergework/branches A /home/vvc/mergework/branches/b1 [mergework]$ svn commit -m Created branch b1 Adding branches Adding branches/b1 Committed revision 1. [mergework]$ svn copy branches/b1 branches/b2 A branches/b2 [mergework]$ svn commit -m Created branch b2 Adding branches/b2 Committed revision 2. [b2]$ touch README [b2]$ svn add README A README [b2]$ svn commit -m Added README Adding b2/README Transmitting file data . Committed revision 3. [b1]$ svn merge -c 3 ^/branches/b2 --- Merging r3 into '.': AREADME [b1]$ svn commit -m Merged r3 into b1 Sendingb1 Adding b1/README Committed revision 4. [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B.
Re: Cherry-picking merges
Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). I would be interested in knowing this very good reason why it can't. I'm not questioning its validity, I'm confident this good reason is a good reason, but as I was surprised too by this behavior, if someone could give an explanation? I would be very interested. Joël
Re: Cherry-picking merges
On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B. Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to record-only 2 of them, it seems. The problem is, we utilize a home made automerge utility that constantly merges all changes from b1 to b2, but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows. Thanks, Vadym
Re: Cherry-picking merges
[b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 and yet another strange thing about it. There is no way to automatically resolve a conflict like this. no matter what flag I use --accept mine-conflict, mine-full, nothing seems to make merge operation happy. I have to issue a separate svn resolve --accept working command afterwards. Vadym
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov vchep...@gmail.com wrote: On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: [b2]$ svn merge --dry-run ^/branches/b1 --- Merging r2 through r4 into '.': C README Summary of conflicts: Tree conflicts: 1 After r3, you'll need to do a '--record-only' merge of r4 into the second branch: (untested) svn merge --record-only -c 4 ^/branches/b1 SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2-b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). Cheers, Daniel B. Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to record-only 2 of them, it seems. I'm pretty sure that you only need to do a record-only of r4. If you do a 'svn merge -r 2:3 ^/branches/b1, I don't think it will actually do anything (other than modify the mergeinfo property). When I get a chance, I'll run a quick test on it (or if you have the WCs from the above example, you could try it yourself). The problem is, we utilize a home made automerge utility that constantly merges all changes from b1 to b2, but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows. You could check if r4 contains mergeinfo for b2, and if so, don't worry about doing the merge between b1-b2, or force it to be record-only. Cheers, Daniel B.
Re: Cherry-picking merges
On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud jconr...@gmail.com wrote: Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't). I would be interested in knowing this very good reason why it can't. I'm not questioning its validity, I'm confident this good reason is a good reason, but as I was surprised too by this behavior, if someone could give an explanation? I would be very interested. After thinking more about it, I believe it's because a revision can contain more than just the merge. For example, if I merge r10 from into a branch, I don't have to commit just that merge. I can have modifications in my working copy, merge, make more modifications, and commit in r11. The svn:mergeinfo will attest that r10 from trunk has been merged in this revision, but it doesn't mean that r11 on the branch is the logical equivalent of r10 on the trunk. I think that best practices suggest that doing things in this manner is a bad idea, and should be discouraged. A revision that contains svn:mergeinfo changes should only contain the file and structure changes logically equivalent to the revisions that have been merged. Cheers, Daniel B.
