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

Re: [merge-tracking] record mergeinfo on wc to wc copy

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2006-07-29 14:12:06 CEST

On Sat, 29 Jul 2006 03:12:49 +0530, Daniel Rall <dlr@collab.net> wrote:

> On Sat, 29 Jul 2006, Madan S. wrote:
> ...
>> As part of the merge-tracking tasks, we need to implement recording
>> of
>> mergeingo on cp.
> Rather, we need to include "copyfrom" history when getting the merge
> info for a path.

IIUC, the 'copyfrom' history is the svn:mergeinfo that already existed in
the source. No?

>> This is needed because copy in itself is equivalent of
>> merging 1-REV of the source into the target (where REV is the revision
>> specified in the cp or the current revision of the wc)
> The easiest way to implement this happens to be adding the merge
> history and "revisions in existence" of a copy's source and setting
> that as the "svn:mergeinfo" for its destination path.
> I think 1-REV might not be correct, since very early revs might
> represent an entirely different object which was moved to a subsequent
> path in a later revision. Do we actually need to do some history
> tracing here to find the oldest rev for our copy source?

hmmm, one one hand, it wouldn't matter because the source wont exist at
those irrelevant revisions - what we call phantom revs in svnmerge.py.

OTOH, it would be nice to eliminate the phantom revs out of the mergeinfo
for performance reasons.

/me goes off to figure out if they could do some history tracing (based on
logs --stop-on-copy?)

>> There are four ways a 'svn cp' can occur:
>> - wc to wc
>> - wc to repos
>> - repos to wc
>> - repos to repos
>> As a first step, am planning to do the wc to wc part. Am thinking on
>> the following lines:
>> 1) Write a new function called append_wc_mergeinfo(target,
>> new_mergeinfo), to prop_get the existing value of svn:mergeinfo on the
>> target path, and to append/merge the provided mergeinfo and set the
>> mergeinfo back into the target's svn:mergeinfo property.
> You'll need both a 'propget' for "svn:mergeinfo" (to account for local
> changes), plus a svn_ra_get_merge_info() to retrieve any inherited
> merge info from parent directories stored in the repos.
> We use/need a similar logic in libsvn_client/diff.c, so we'll want to
> share code there.

yeah, and I think we can use the existing update_wc_merge_info() function.
(Which brings me to another point in a tangential direction - can we
abstract the parse_merge_info() call into update_wc_merge_info()?
Currently we call parse_merge_info() before calling

>> 2) Call append_wc_mergeinfo() in svn_wc_copy2() just before calling
>> svn_wc_adm_close().
> That looks like a likely spot to inject this behavior.
> Do we need it to be "loggy"?

I do not understand logginess. Will do some research and get back to you.
Would be great if you can detail your thoughts a bit more.

Madan U S

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 29 08:43:31 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.