Daniel Becroft <djcbecroft_at_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.
- application/pgp-signature attachment: stored
Received on 2010-05-02 01:56:32 CEST