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

Re: [RFC] Identifying copy/move sources

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-04-02 16:44:33 CEST

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.

Mark Phippard
Received on Mon Apr 2 16:44:49 2007

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.