gnu-arch-users
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]