On Fri, Apr 30, 2010 at 10:52 PM, Greg Troxel <gdt_at_ir.bbn.com> wrote:
>
> Daniel Becroft <djcbecroft_at_gmail.com> writes:
>
> > On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud <jconraud_at_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.
>
> The problem is that you have to commit on two branches at once. The
> workflow is (very roughly):
>
> go onto merge target branch
> svn merge source branch
> svn commit => making C
>
> switch to source branch
> svn merge -c $C --record-only target-branch
> svn commit
>
> We ended up writing scripts to do both of these things, which worked
> because we had a structured repository.
>
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).
> 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.
> 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.
>
> > 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.
>
> Absolutely. This isn't a "clean changeset" and is madness; everyone
> should prohibit it.
>
Completely agree.
Cheers,
Daniel B.
Received on 2010-05-01 01:02:19 CEST