Re: [Gnu-arch-users] Re: archzoom

[Stefan Monnier]

>> For me the problem stops right here: `tla changes' necessarily operates on
>> the whole project, just like all other commands.  Performance would be
>> drastically improved if `tla' only looked at the files it needs to perform
>> a given command, and if the user could specify those files.
>> I generally operate within a subtree of my `emacs' project.  And when
>> I commit, I generally know which files I'm committing, so I can pass them to
>> `tla' just fine.  Part of this is a UI issue, other part is implementation.
>> But the ID-tagging and the repository format seem innocent here.

> Well, when one runs `tla changes', that's typically because they want to
> know which files have changed.

But I generally know I only care about a particular subset of the files
(either because I want to ignore the others, or because I already know the
changes are only there).
Sometimes I can use `file-diff' instead which can be much more efficient
(except when it does a stupid revlib consistency check which brings us back
to full-tree latency), but `file-diff' is much too restrictive.

> If you are certain of what changed, you just don't run `tla changes'.  ;-)

Sure you do: how else do you suggest I can get the actual diff?

> Then there are `commit' and `undo' that can take a list of files as an
> argument, but that doesn't make any difference performance-wise.  For
> instance, I think both commands run `tree-lint' before actually doing
> the operation.

Yup: that's exactly the "other part is implementation" bit I was
thinking of.  There's no good reason why `comit' and `undo' need to do
a full-tree operation when handed a list of files as argument.
And of course, the list should allow dirs as well as files.

>> Other implementation limitation: it always constructs a whole tree when it
>> really only needs "file FOO from revision BAR".
> Not if revision BAR is already cached (in a revlib or pristine tree).

You mean "not if it's already built"?  Well, duh!

> Also, since changesets describe changes to a whole tree, applying them
> really requires that tree.

No.  The changesets have structure: you can easily get the patch you need
for the particular file you're interested in (if there is one, or just skip
the changeset else).  It is true, tho, that you need to download the whole
changesets rather than only the relevant part.  But this hasn't been
a bottleneck and with good changeset caching it shouldn't be a big deal.


        Stefan