On Sat, 29 Jul 2006, Madan S. wrote:
> 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?
The value for any pre-existing "svn:mergeinfo" propery should already
be being copied by the 'copy' operation.
The "copyfrom" history is every revision where the merge source
existed at the path it's pegged at for the 'copy' operation.
> >>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.
It would matter to the current merge tracking implementation (which
assumes that "svn:mergeinfo" is accurate and follows it blindly),
since some other object may've existed at the copy source's path in
earlier revisions.
> OTOH, it would be nice to eliminate the phantom revs out of the mergeinfo
> for performance reasons.
Yup, doing the history tracing on every merge -- to eliminate phantom
revs -- doesn't strike me as the most performant implementation.
...
> >> 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:
...
> >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().)
The call, yes. The routine, no (since we call it elsewhere).
It's already like this in my WC as I've been working on the
notification handling code (for skips, etc.). I'll factor some of
that out and make an incremental commit today.
> >> 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.
IIUC, making a WC routine "loggy" consists of writing a set of
commands for an operation into a file (in XML, I believe), then
executing the commands in sequence after they've all been written to
the file.
- application/pgp-signature attachment: stored
Received on Mon Jul 31 19:53:29 2006