[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: log-buf-len dynamic
From: |
Samium Gromoff |
Subject: |
[Gnu-arch-users] Re: log-buf-len dynamic |
Date: |
Thu, 02 Oct 2003 13:52:31 +0400 |
User-agent: |
Wanderlust/2.11.7 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
To: Samium Gromoff <address@hidden>
Subject: Re: log-buf-len dynamic
From: Linus Torvalds <address@hidden>
Date: Fri, 26 Sep 2003 08:31:25 -0700 (PDT)
Message-ID: <address@hidden>
Content-Length: 2678
On Fri, 26 Sep 2003, Samium Gromoff wrote:
>
> Well, i sincerely hope that since it was rewritten in C
> (now called "tla"), its performance has gained enough for you to take
> some time to examine it more closely.
Yeah, I've seen some people start to use it, and that is bound to improve
things.
> > I take it you haven't tried bitkeeper?
>
> I did but my experience with it is far less than remotely
> extensive.
There's two things about bitkeeper: (a) it does get the distribution
right, and (b) is is actually very polished.
I think you get (a), but (b) includes things like the patch import system
that has an automatic "renametool", which means that if the patch removes
a file and creates another, you can choose to view it as a file rename.
That's a big thing for me, since more than 50% of all work is still done
in patches (well, as far as I'm concerned, 95% of all work is done as
patches, but that's just because when things are done in BK, I just do a
single "bk pull" and I get several changesets, of course).
The three-way graphical merge is also very very useful. I don't end up
needing it that often (thank Gods), but when I do, it's very nice.
And of course, the sanity checking has actually found problems at times.
It ends up beign the slowest part of most BK operations (doing a full
checksum verification), but it's made BK bugs (they've happened a few
times) be noticed immediately rather than corrupt the tree, and it has
also several times found dodgy hardware or some kernel bugs.
Once you have everything in a repository and you depend on the internal
correctness of the repostitory, you have to be _careful_. It's not too bad
if there is just a tar-file with no real metadata - just the source. If
corruption happens, it's obvious. But with real metadata in the project,
having a careful "fsck" that verifies that everything is right has been a
really good thing.
(For example: I've seen corrupted CVS repo's a few times, and you _really_
have to know what you're doing with them. Nasty. The "fsck" + replication
really helps here)
I've only checked out arch occasionally (I did notice there were now
multiple versions of it, and was happy to see the aggressive one moving to
C), but as far as I can tell it doesn't do any of this.
There's another project - OpenCM. They don't do replication yet, but at
least they seem to understand it and think that they can do it (unlike the
SVN people). I like their secure hashes - checksums on steroids - but at
least a year ago or so they had problems with the size of the archive
(secure hashes are inherently pretty big and totally non-compressible).
Linus
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnu-arch-users] Re: log-buf-len dynamic,
Samium Gromoff <=