Hi, Stefan Monnier <[EMAIL PROTECTED]> 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. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
