[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: archzoom
From: |
Ludovic Courtès |
Subject: |
Re: [Gnu-arch-users] Re: archzoom |
Date: |
Wed, 11 Oct 2006 10:40:17 +0200 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi,
Stefan Monnier <address@hidden> writes:
> 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. If you are certain of what changed, you
just don't run `tla changes'. ;-)
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.
> 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).
Also, since changesets describe changes to a whole tree, applying them
really requires that tree. I believe GIT and friends are usually faster
precisely because they store snapshots (full revisions) rather than
changesets. So I believe this "limitation" stems from the design rather
than the implementation of Arch (and this is what Arch 2 was supposed to
address).
Thanks,
Ludovic.