Re: [RFC] Identifying copy/move sources

On Mon, 02 Apr 2007, Mark Phippard wrote:

> On 4/2/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> >
> >Daniel Rall wrote:
> >> Goal: I need a convenient and efficient way to identify the immediate
> >> copy/move source path and revision of a specified path and revision.
> >
> >So, you need svn_fs_closest_copy(), but via the RA layers.
> >
> >> Use case: The case I have in mind right now revolves around use of
> >> this copyfrom info in a 'merge' dialog, as part of an algorithm for
> >> suggesting the most likely merge source (e.g. for a feature branch
> >> forked off of trunk).
> >
> >Hrm. This seems (to me, at first glance) like a stab in the dark which
> >falls over rather quickly in some common scenarios, such as branching for
> >code re-organization, where suddenly a directory's immediately copy/move
> >source path and revision haven't anything to do with the branch creation.
> >
> >Maybe you can explain the full vision here a bit?
>
>
> Picture a merge UI. One of the primary values you need to enter is the
> merge source URL. In a GUI, it makes a lot of sense for this to be an
> editable combo box loaded with values from the svn:mergeinfo property. Some
> value should ideally be loaded as the default value. The copy source for
> the item is probably the best default value.
>
> I think you could conceivably build a UI or tool that shows the ancestry of
> an item using the information. Basically get the copy source for the item,
> then the copy source for that item etc... You could not quite build a
> CVS-style version tree this way, but for some situatons it could let you do
> something useful. Basically, if an efficient API can be produced to get
> this info, it just seems worthwhile to have it.

We talked this over a bit on IRC, then Mike and I continued the
conversation on the phone. Mike agreed that the functionality was
interesting, and suggested a way to both make it even more
interesting, and more neatly integrate it into Subversion in a
cleaner, cheaper, and more efficient fashion:

  svn log --copies-only

Such an interface would allow us to pass a flag through to the
repository and FS by tweaking an existing RA API (rather than adding
an entirely new API), allowing access to svn_fs_closest_copy() by
implementing the --copies-only flag using it, rather than the full
history tracing of typical calls to 'svn log'. Using a variation that
equates to 'svn log --copies-only --limit=1' (or '--copies-only
--stop-on-copy') would allow us to determine the most recent copy.
Dropping the parameter would provide access to the entire branch
history of a path.

I'm planning on implementing this RSN, assuming no one has a problem
with it, or points out any serious complications that we might've
overlooked.

Thanks, Dan