Daniel Rall wrote:
> 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.
For compat with old servers, I was thinking that the client-side code looks
for a special flag in the server's 'log' response which says, "Yeah, I heard
you, and I'm sending only copies down the pipe." In the absence of such a
flag, the client assumes the server didn't grok the --copies-only part of
the request, and is going to send all the log revisions. The client then
performs the copies-only filtering itself.
Unfortunately, that only works if the client requested changed-paths
(verbose mode) to be in the log items (since that's the data used to perform
the client-side filtering). :-(
So maybe there's no compat mode other than for the client, in the absense of
the special flag, to raise SVN_ERR_UNSUPPORTED_FEATURE. Or we could do our
best, only raising that error if a) the server won't support --copies-only
and b) a non-verbose log request was made.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Apr 3 04:56:32 2007