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

Re: RA->get_repos_root() needed

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-10-13 23:10:35 CEST

On Mon, Oct 13, 2003 at 03:21:26PM -0500, kfogel@collab.net wrote:
> mark benedetto king <mbk@lowlatency.com> writes:
> > The log message receiver gets passed a hash of "changed_paths". The
> > keys on this hash are absolute repository-paths (e.g. "/trunk/INSTALL").
> > In order to know what key to used to inspect this hash for changes, I need
> > to be able to split "http://svn.collab.net/repos/svn/trunk/INSTALL" into its
> > repository-URL and path components.
> >
>
> A thought: couldn't you take the initial log message (the youngest
> one), find the target file path in the file list, and "lay it over"
> the original URL starting from the right edge, using the difference to
> discover the non-path portion of the URL?

The trick is the "find the target file path" part. You don't know what
you're looking for, so you have to iterate over all the keys, and
take the shortest path with longest tail-match. At least, I think that
is both necessary and sufficient, given the current API.

> > Anyway, in the meantime, I have a nasty hack that will work (I'll iterate
> > through the keys, taking the shortest one with the longest tail-match on
> > my URL).
>
> Sure, whatever works!

Yes.

>
> So, a question: Is the current blame output formally incorrect under
> some circumstances? If it is, we'll need an issue -- which I'm happy
> to file, just say the word. We can't enable the feature in 1.0 unless
> the output is correct, IMHO. (Nor should we try to solve issue #960
> before 1.0, but hopefully this 'blame' problem can be solved another
> way -- brute force is fine :-) ).

It produces an error when run without --strict on files that were moved
or copied in the revision range specified. I don't think the output is
ever incorrect (i.e., assigns blame to the wrong revision), but I could
be wrong.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 13 23:11:21 2003

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.