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

Re: AW: How to find out the rev number where a file was deleted?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sun, 28 Nov 2010 21:20:28 +0100

On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100:
>> The real problem is that we want to be able to answer these questions
>> very fast, and some design aspects work against this. For instance,
>> FSFS by design does not allow modifying old revisions. So where do
>> we store the copy-to information for a given path_at_N?
> copy-to information is immutable (never changes once created), so we
> could add another hierarchy (parallel to revs/ and revprops/) in which
> to store that information.  Any 'cp foo_at_N bar' operation would need to
> create/append a file in that hierarchy.
> Open question: how to organize $new_hierarchy/16/16384/** to make it
> efficiently appendable and queryable (and for what queries? "Iterate
> all copied-to places" is one).
> Makes sense?

I'm not sure. But there is another alternative: while we wait for
FS-NG (or another solution like you propose), one could implement the
"slow" algorithm within the current design. Just automating what a
user (or script) currently does when looking for this information,
i.e. a binary search.

Of course it would be slow, but it would certainly already provide
value. At the very least, it saves users a lot of time searching FAQ's
and list archives, wondering why this doesn't work, understanding the
design limitations, and then finally implementing their own script or
doing a one-time manual search.

Then, when FS-NG arrives, or someone comes up with a way to index this
information, it can be "optimized".

I don't know if there would be fundamental problems with that, apart
from the fact that someone still needs to implement it of course ...


Received on 2010-11-28 21:21:28 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.