[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r20515 - branches/merge-tracking/subversion/libsvn_client

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-07-11 20:52:15 CEST

On Tue, 11 Jul 2006, Madan S. wrote:

> On Tue, 11 Jul 2006 02:11:06 +0530, <dlr@tigris.org> wrote:
> >Author: dlr
> >Date: Mon Jul 10 13:41:05 2006
> >New Revision: 20515
> >
> >Modified:
> > branches/merge-tracking/subversion/libsvn_client/diff.c
> >
> >Log:
> >On the merge-tracking branch: Avoid discarding any additional merge
> >info which entered the WC as the result of a property merge.
> >
> >* subversion/libsvn_client/diff.c
> > (do_merge, do_single_file_merge): Re-parse the merge info reflected
> > by the WC before using it to update its merge info based on the
> > revision ranges which were just merged in.
> Thank you for applying the patch. I would like to point out one thing
> though. Even though we have this change in the do_single_file_merge()
> function, the fix alone would not have fixed anything wrt single file
> merges.

Storing merge history on a per-versioned resource (rather than only
per-parent directory) basis is definitely the long-term goal here.

If we parse merge info for a file from the WC (e.g. "/trunk/foo:3-7"),
then calculate the revision ranges remaining in the requested merge
(e.g. "-r7:9", when "-r5:9" was requested), during the merge of those
revision ranges into the WC we may change "svn:mergeinfo" property for
that file (e.g. to "/trunk/foo:2-7"). When we go to update the merge
info pertaining to that file, we need to re-parse its merge info from
the WC before we include the ranges for the delta(s) we just applied
(updating it to "/trunk/foo:2-9" instead of "/trunk/foo:3-9").

> This is because of the missing API I described in
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=117585.
> Let me explain in detail. On merge of a single file, neither the
> current source nor the current target have all the merge info pertaining
> to the file. This info is stored in one of its parents or grandparents due
> to eliding(This also applies to directories with merge info elided in
> parent directories). Because of this, our single file merges simply assume
> that the source has no relevant mergeinfo and proceeds to only record the
> current merge in the target.
> We need to introduce this special case of elided merge of the
> svn:mergeinfo property before this change can show its effect on
> single-file merges.
> Just pointing out, in case this isn't immediately obvious.

While we have recently been playing the "get the simple case working
first" game, Danny B. added code to handle this situation 3 weeks ago
to our current (versioned resource-specific) RA API,

  • application/pgp-signature attachment: stored
Received on Tue Jul 11 20:53:01 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.