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

Re: svn_ra_get_file_revs2 vs. blame vs. FS API

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Wed, 19 Feb 2014 19:08:47 +0000

On Sun, Feb 16, 2014 at 10:09 PM, Bert Huijben <bert_at_qqmail.nl> wrote:

> Hi,
>
>
>
> I don't believe the -g implementation really works... It is a nice proof of
> concept, but it doesn't handle many merge scenarios. (It only works if you
> assume branches that are kept closely in sync).
>

That's good news. I found the processing part confusingly simply.
OTOH, it seems to yield fair approximations of what actually happened.

 But the changes you suggest look much broader than the -g mode.
>

Not necessarily. I'd like to get the tests pass with FSX as well
without replicating dubious behaviour from FSFS. With the
feedback from Julian, I think we have an idea how to clean
up the mess in between FS code and blame.

> I don't see a problem with changing the requirements for the use merge
> tracking mode as that already breaks most rules about a direct version
> path, but I would be afraid that we do break backward compatibility if this
> also changes the behavior for not-g mode.
>

Duly noted. The critical case here would be the impact of "svn cp"
on the blame output. But I don't expect a problem here. And I
don't intend the change the blame output for the non-g case.

The comments on 'svn_ra_get_file_revs2 always accept a delta handler' don't
> make sense for me. That function has a delta handler as argument and I
> don't see scenarios where it doesn't accept that argument?
>

See my reply to Julian's post. There is a bit back&forth between
svn_fs_get_file_revs2 and its handler.

Perhaps you should explain what the real problem is what you try to solve,
> instead of assuming that everybody has a deep knowledge about both the fs
> internals and this very specific api that drives blame (and several third
> party tools that want to obtain all versions of a file in the most
> efficient way possible).
>

Well, this has been one of those "late at night - let's wrap things up
posts" ;)

The problem is simply: How to stop blame -g rely on implementation
specifics of svn_fs_contents_changed? Background: The logic FSX
uses now creates less memory and storage overhead and is legal
according to the FS API spec - but it brakes "blame -g".

-- Stefan^2.
Received on 2014-02-19 20:09:20 CET

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.