[Gnu-arch-users] Re: log-buf-len dynamic

[Samium Gromoff]

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