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
update_wc_merge_info().)
>> 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.
Regards,
Madan U S
www.symonds.net/~madan
---------------------------------------------------------------------
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