People just resort to darcs changes -v.  And the output isn't very nice, apparently.

It may be worth considering a rewrite/rethink.

I vote for this as well, but I'm marking it as "deferred" for now, since it's a
wishlist/feature item.

Actually, I think we're aiming to have this fixed for darcs 2.1...

We may have to renegotiate this as time goes on, however.

See http://bugs.darcs.net/issue124 for the proposed solution to this: creating a
cache that maps filenames to the patches that modify them.

On Wed, Oct 08, 2008 at 09:22:21AM -0000, Eric Kow wrote:
> See http://bugs.darcs.net/issue124 for the proposed solution to this: creating a
> cache that maps filenames to the patches that modify them.

I'll just briefly mention for the record that there are obviously
multiple approaches one could use for creating such a cache.

1. One could create a copy of the hashed_inventory with mention of all
the files touched included.

2. One could create a directory tree mimicing the pristine cache, in
which the contents of each file is an inventory of all patches
affecting that file.

The latter is much faster for looking up patches affecting a given
file, but it's quite a bit of work.  Of course, there are innumerable
variations on this, such as storing copies of the pieces of patches
that affect each file (so we wouldn't have to read in the entire patch
when running annotate).

I suspect 2 will actually be the easiest to deal with in the long run.
It could reuse almost all the HashedIO code to maintain the cache.
The only real downside of 2 is that it doesn't easily handle the case
of files that have been deleted, particularly when a newer file has
been added that has the same name (or an older file has been renamed
over the deleted file's name).  But in these rare cases we could in
the worst case scenario use the existing code.

On the other hand, if we had a mapping of current filename to
PatchInfo of patch that created the file + its original name, then we
could use that immutable file id (which still isn't consistent across
repositories, or across darcs optimize --reorder) to look up the
patches that affect the file.  This might allow a someone simpler
approach in which we can drop the existing annotate code in favor of
the optimized code (instead of almost never using it).

But ultimately, essentially any reasonable cache layout will work, and
it's up to whoever decides to implement it.  We just need to be able
to find out which patches affect a given file without parsing every
patch in the repository.

David

Hi Benedikt, I'm assigning this to you because you have been working on the
filecache stuff.  Thanks very much!

Let's try to get this in by 2.3... Benedikt, do you have any news to share on 
this? We are all looking forward. :)

I've created a filecache-specific ticket on issue1566.

Just a data point: I have darcs-2.3.0 here on a Linux server, and when using the repo 
from http://allmydata.org/source/tahoe/trunk-hashedformat , the following command takes 
45 to 60 seconds:

darcs annotate --xml-output --match "hash 20091127055900-66853-
b166fc807226ca10c1ea66864896646b85d67fcb.gz" docs/frontends/webapi.txt

This is way too long!  It would be great if it could be reduced to 1/100 of that runtime.

So, that "darcs annotate" command that I mentioned in my previous note is the 
one that produces this web page: 
http://allmydata.org/trac/tahoe/browser/docs/frontends/webapi.txt?
annotate=blame&rev=4112 .  If that web page gives you an error then the "darcs 
annotate" took too long or ran out of RAM and was killed.  If that web page 
gives you a nice annotation of a text file, then it worked!

Our new goal is to have this in 2.6.0 HEAD soon after the 2.5 release is
out the door.

Resolved by patch index.