[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: bitkeeper vs tla

From: John Meinel
Subject: Re: [Gnu-arch-users] Re: bitkeeper vs tla
Date: Thu, 23 Sep 2004 22:40:16 -0500
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Dustin Sallings wrote:


I use perforce at work, and I can say that the speed difference is really worth any perceived inconvenience there. For me, I've got a vim macro (\o) that will open whatever file I'm working on for edit, and another (\pa) that will open the current file for add.

I spent a good hour and a half playing with arch trees on a plane trying to make some minor changes. Commits would take a good five minutes for each change (after about as long for a changes). It was basically unusable.

I was working on a branch of a tree with a lot of patches (migrated directly from p4 changesets) and a lot of files using explicit tagging and a greedy revlib if anyone's wondering.

Well, if you can do hard-linked source trees, I've found that my 'tla changes' time goes *way* down.

However, I also use arch on windows, where it is even worse. I have at times done "tla commit" and then I walk away and go do something else so that I'm not just sitting there waiting for it to finish.

I do sort of wish that arch had a "don't diff unless the timestamp has been altered". Most OS's respect timestamps. So when you write to a file, the timestamp is updated. I may be misunderstanding what arch does, it might already have this, and it's just the overhead of stat'ing 3000 files. (+3000 from the pristine/revlib).

I also know that Tom has proposed some ideas about saying 'tla commit --this-directory' so that it doesn't have to look everywhere, and can focus on what you've told it.

But his overall plans seemed much more involved, so I'm not sure where that is going.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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