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