Re: Kernel SCM saga.. (bk license?)

On Tue, 12 Apr 2005, Kedar Sovani wrote: >I was wondering if working on git, is in anyway, in violation of the >Bitkeeper license, which states that you cannot work on any other SCM >(SCM-like?) tool for "x" amount of time after using Bitkeeper ? Technically, yes, it is. However, as BitMover has

Re: Kernel SCM saga..

Hi! > > It's possible to generate another object with the same hash, but: > > Yeah - the real check is that the modified object has to > compile and do something useful for someone (the cracker > if no one else). > > Just getting a random bucket of bits substituted for a > real kernel source

Re: Kernel SCM saga.. (bk license?)

Kedar Sovani <[EMAIL PROTECTED]> wrote: > I was wondering if working on git, is in anyway, in violation of the > Bitkeeper license, which states that you cannot work on any other SCM > (SCM-like?) tool for "x" amount of time after using Bitkeeper ? That's valid for the new BK license only which

Re: Kernel SCM saga.. (bk license?)

I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for "x" amount of time after using Bitkeeper ? Kedar. On Apr 8, 2005 10:12 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Thu, 7

Re: Kernel SCM saga.. (bk license?)

I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for x amount of time after using Bitkeeper ? Kedar. On Apr 8, 2005 10:12 AM, Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 7 Apr

Re: Kernel SCM saga.. (bk license?)

Kedar Sovani [EMAIL PROTECTED] wrote: I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for x amount of time after using Bitkeeper ? That's valid for the new BK license only which probably

Re: Kernel SCM saga..

Hi! It's possible to generate another object with the same hash, but: Yeah - the real check is that the modified object has to compile and do something useful for someone (the cracker if no one else). Just getting a random bucket of bits substituted for a real kernel source file isn't

Re: Kernel SCM saga.. (bk license?)

On Tue, 12 Apr 2005, Kedar Sovani wrote: I was wondering if working on git, is in anyway, in violation of the Bitkeeper license, which states that you cannot work on any other SCM (SCM-like?) tool for x amount of time after using Bitkeeper ? Technically, yes, it is. However, as BitMover has

Re: Kernel SCM saga..

On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote: > > On 2005-04-11, at 04:26, Miles Bader wrote: > > >Marcin Dalecki <[EMAIL PROTECTED]> writes: > >>Better don't waste your time with looking at Arch. Stick with patches > >>you maintain by hand combined with some scripts containing a

Re: Kernel SCM saga..

On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote: On 2005-04-11, at 04:26, Miles Bader wrote: Marcin Dalecki [EMAIL PROTECTED] writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of

Re: Kernel SCM saga..

On 2005-04-11, at 04:26, Miles Bader wrote: Marcin Dalecki <[EMAIL PROTECTED]> writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of apply commands and you should be still more productive then when using

Re: Kernel SCM saga..

Marcin Dalecki <[EMAIL PROTECTED]> writes: > Better don't waste your time with looking at Arch. Stick with patches > you maintain by hand combined with some scripts containing a list of > apply commands and you should be still more productive then when using > Arch. Arch has its problems, but

Re: Kernel SCM saga..

On Monday 11 April 2005 12:33 am, you wrote: [..] > Well, I followed some of the instructions to mirror the kernel tree on > svn.clkao.org/linux/cvs, and although it took around 12 hours to import > 28232 versions, I seem to have a mirror of it on my own subversion > server now. I think the

Re: Kernel SCM saga..

On Thu, Apr 07, 2005 at 02:29:24PM -0400, Daniel Phillips wrote: > On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote: > > On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote: > > > Three years ago, there was no fully working open source distributed scm > > > code base to use as a starting

Re: Kernel SCM saga..

Ingo wrote: > not the compression of every file separately. ok -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the

Re: Kernel SCM saga..

Andrea Arcangeli schrieb am 2005-04-09: > On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: > > really designed for something like a offline http grabber, in that you can > > just grab files purely by filename (and verify that you got them right by > > running sha1sum on the

Re: Kernel SCM saga..

> It's possible to generate another object with the same hash, but: Yeah - the real check is that the modified object has to compile and do something useful for someone (the cracker if no one else). Just getting a random bucket of bits substituted for a real kernel source file isn't going to get

Re: Kernel SCM saga..

* Paul Jackson <[EMAIL PROTECTED]> wrote: > Ingo wrote: > > With default gzip it's 3.3 seconds though, > > and that still compresses it down to 57 MB. > > Interesting. I'm surprised how much a bunch of separate, modest sized > files can be compressed. sorry, what i measured was in essence the

Re: Kernel SCM saga..

Ingo wrote: > With default gzip it's 3.3 seconds though, > and that still compresses it down to 57 MB. Interesting. I'm surprised how much a bunch of separate, modest sized files can be compressed. I'm unclear what matters most here. Space on disk certainly isn't much of an issue. Even with

Re: Kernel SCM saga..

ll non-trivial in terms of computation needed > > Message-ID: <[EMAIL PROTECTED]> > From: Linus Torvalds <[EMAIL PROTECTED]> > Subject: Re: Kernel SCM saga.. > Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT) > > ... > > Lin

Re: Kernel SCM saga..

On Sun, Apr 10, 2005 at 11:24:07AM +0200, Giuseppe Bilotta wrote: > On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote: > > > I've recently made some improvements recently which will reduce the > > memory use > > Does this include check for redundancy? ;) Yeah, the only catch is that if the

Re: Kernel SCM saga..

* Paul Jackson <[EMAIL PROTECTED]> wrote: > These 16817 files consume: > > 224 MBytes uncompressed and >95 MBytes compressed > > (using zlib's minigzip, on a 4 KB page reiserfs.) that's a 42.4% compressed size. Using a (much) more CPU-intense compression method (bzip -9), the

Re: Kernel SCM saga..

* David S. Miller <[EMAIL PROTECTED]> wrote: > On Fri, 8 Apr 2005 22:45:18 -0700 (PDT) > Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > Also, I don't want people editing repostitory files by hand. Sure, the > > sha1 catches it, but still... I'd rather force the low-level ops to use > > the

Re: Kernel SCM saga..

o so... Message-ID: <[EMAIL PROTECTED]> From: Linus Torvalds <[EMAIL PROTECTED]> Subject: Re: Kernel SCM saga.. Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT) ... Linus (*) yeah, yeah, I know about the current theoretical case, and I don't care. Not o

Re: Kernel SCM saga..

On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote: > I've recently made some improvements > recently which will reduce the memory use Does this include check for redundancy? ;) -- Giuseppe "Oblomov" Bilotta Hic manebimus optime - To unsubscribe from this list: send the line "unsubscribe

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Linus Torvalds wrote: The biggest irritation I have with the "tree" format I chose is actually not the name (which is trivial), it's the part. Almost everything else keeps the in the ASCII hexadecimal representation, and I should have done that here too. Why? Not because it's

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Linus Torvalds wrote: The biggest irritation I have with the tree format I chose is actually not the name (which is trivial), it's the sha1 part. Almost everything else keeps the sha1 in the ASCII hexadecimal representation, and I should have done that here too. Why? Not

Re: Kernel SCM saga..

On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote: I've recently made some improvements recently which will reduce the memory use Does this include check for redundancy? ;) -- Giuseppe Oblomov Bilotta Hic manebimus optime - To unsubscribe from this list: send the line unsubscribe

Re: Kernel SCM saga..

: Linus Torvalds [EMAIL PROTECTED] Subject: Re: Kernel SCM saga.. Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT) ... Linus (*) yeah, yeah, I know about the current theoretical case, and I don't care. Not only is it theoretical, the way my objects are packed you'd have

Re: Kernel SCM saga..

* David S. Miller [EMAIL PROTECTED] wrote: On Fri, 8 Apr 2005 22:45:18 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Also, I don't want people editing repostitory files by hand. Sure, the sha1 catches it, but still... I'd rather force the low-level ops to use the proper helper

Re: Kernel SCM saga..

* Paul Jackson [EMAIL PROTECTED] wrote: These 16817 files consume: 224 MBytes uncompressed and 95 MBytes compressed (using zlib's minigzip, on a 4 KB page reiserfs.) that's a 42.4% compressed size. Using a (much) more CPU-intense compression method (bzip -9), the

Re: Kernel SCM saga..

On Sun, Apr 10, 2005 at 11:24:07AM +0200, Giuseppe Bilotta wrote: On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote: I've recently made some improvements recently which will reduce the memory use Does this include check for redundancy? ;) Yeah, the only catch is that if the

Re: Kernel SCM saga..

] From: Linus Torvalds [EMAIL PROTECTED] Subject: Re: Kernel SCM saga.. Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT) ... Linus (*) yeah, yeah, I know about the current theoretical case, and I don't care. Not only is it theoretical, the way my objects

Re: Kernel SCM saga..

Ingo wrote: With default gzip it's 3.3 seconds though, and that still compresses it down to 57 MB. Interesting. I'm surprised how much a bunch of separate, modest sized files can be compressed. I'm unclear what matters most here. Space on disk certainly isn't much of an issue. Even with

Re: Kernel SCM saga..

* Paul Jackson [EMAIL PROTECTED] wrote: Ingo wrote: With default gzip it's 3.3 seconds though, and that still compresses it down to 57 MB. Interesting. I'm surprised how much a bunch of separate, modest sized files can be compressed. sorry, what i measured was in essence the tarball.

Re: Kernel SCM saga..

It's possible to generate another object with the same hash, but: Yeah - the real check is that the modified object has to compile and do something useful for someone (the cracker if no one else). Just getting a random bucket of bits substituted for a real kernel source file isn't going to get

Re: Kernel SCM saga..

Andrea Arcangeli schrieb am 2005-04-09: On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting

Re: Kernel SCM saga..

Ingo wrote: not the compression of every file separately. ok -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line

Re: Kernel SCM saga..

On Thu, Apr 07, 2005 at 02:29:24PM -0400, Daniel Phillips wrote: On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote: On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote: Three years ago, there was no fully working open source distributed scm code base to use as a starting point,

Re: Kernel SCM saga..

On Monday 11 April 2005 12:33 am, you wrote: [..] Well, I followed some of the instructions to mirror the kernel tree on svn.clkao.org/linux/cvs, and although it took around 12 hours to import 28232 versions, I seem to have a mirror of it on my own subversion server now. I think the

Re: Kernel SCM saga..

Marcin Dalecki [EMAIL PROTECTED] writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of apply commands and you should be still more productive then when using Arch. Arch has its problems, but please

Re: Kernel SCM saga..

On 2005-04-11, at 04:26, Miles Bader wrote: Marcin Dalecki [EMAIL PROTECTED] writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of apply commands and you should be still more productive then when using

Re: Kernel SCM saga..

Linus Torvalds writes: > NOTE! I detest the centralized SCM model, but if push comes to shove, > and we just _can't_ get a reasonable parallell merge thing going in > the short timeframe (ie month or two), I'll use something like SVN > on a trusted site with just a few committers, and at least

Re: Kernel SCM saga..

Linus wrote: > Almost everything > else keeps the in the ASCII hexadecimal representation, and I > should have done that here too. Why? Not because it's a - hey, the > binary representation is certainly denser and equivalent Since the size of ASCII sha1's is only about 18% larger than the

Re: Kernel SCM saga..

Chris wrote: > How many is alot? Are we talking 100k, 1m, 10m? I pulled some numbers out of my bk tree for Linux. I have 16817 source files. They average 12.2 bitkeeper changes per file (counting the number of changes visible from doing 'bk sccslog' on each of the 16817 files). These 16817

Re: Re: Re: Kernel SCM saga..

On Apr 10, 2005 2:42 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter > where Phillip Lougher <[EMAIL PROTECTED]> told me that... > > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > > > > > FWIW, I made few small

Re: Re: Re: Kernel SCM saga..

Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter where Phillip Lougher <[EMAIL PROTECTED]> told me that... > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > > > FWIW, I made few small fixes (to prevent some trivial usage errors to > > cause cache corruption)

Re: Re: Kernel SCM saga..

On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > FWIW, I made few small fixes (to prevent some trivial usage errors to > cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and > gitlog.sh - heavily inspired by what already went through the mailing > list.

Re: Kernel SCM saga..

David wrote: > recovery is more difficult when you corrupt some > file in your repository. Agreed. I too have recovered RCS and SCCS files by hand editing. Linus wrote: > I don't want people editing repostitory files by hand. Tyrant !;) >From Wikipedia: A tyrant is a usurper of rightful

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 04:13:51PM -0700, Linus Torvalds wrote: > > I understand the arguments for compression, but I hate it for one > > simple reason: recovery is more difficult when you corrupt some > > file in your repository. I've had this too. Magic binary blobs are horrible here for data

Re: Kernel SCM saga..

Roman Zippel wrote: It seems you exported the complete parent information and this is exactly the "nitty-gritty" I was "whining" about and which is not available via bkcvs or bkweb and it's the most crucial information to make the bk data useful outside of bk. Larry was previously very clear

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, David S. Miller wrote: > > I understand the arguments for compression, but I hate it for one > simple reason: recovery is more difficult when you corrupt some > file in your repository. Trust me, the way git does things, you'll have so much redundancy that you'll have to

Re: Kernel SCM saga..

On Fri, 8 Apr 2005 22:45:18 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Also, I don't want people editing repostitory files by hand. Sure, the > sha1 catches it, but still... I'd rather force the low-level ops to use > the proper helper routines. Which is why it's a raw zlib

Re: Kernel SCM saga..

* David Lang: >> Databases supporting replication are called high end. You forgot >> the cats dance around the network this issue involves. > > And Postgres (which is Free in all senses of the word) is high end by this > definition. I'm not aware of *any* DBMS, commercial or not, which can

Re: Kernel SCM saga..

On Sat, 2005-04-09 at 19:40 +0200, Roman Zippel wrote: > On Sat, 9 Apr 2005, Eric D. Mudama wrote: > > > For example bk does something like this: > > > > > > A1 -> A2 -> A3 -> BM > > > \-> B1 -> B2 --^ > > > > > > and instead of creating the merge changeset, one could merge

Re: Kernel SCM saga..

On 2005-04-09, at 17:42, Paul Jackson wrote: Marcin wrote: But what will impress you are either the price tag the DB comes with or the hardware it runs on :-) The payroll for the staffing to care and feed for these babies is often impressive as well. Please don't forget the bill from the electric

[PATCH] Re: Kernel SCM saga..

Dear diary, on Sat, Apr 09, 2005 at 09:08:59AM CEST, I got a letter where "Randy.Dunlap" <[EMAIL PROTECTED]> told me that... > On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: ..snip.. > | FWIW, I made few small fixes (to prevent some trivial usage errors to > | cause cache corruption) and

Re: Kernel SCM saga..

Hi, On Sat, 9 Apr 2005, Eric D. Mudama wrote: > > For example bk does something like this: > > > > A1 -> A2 -> A3 -> BM > > \-> B1 -> B2 --^ > > > > and instead of creating the merge changeset, one could merge them like > > this: > > > > A1 -> A2 -> A3 -> B1 -> B2 >

Re: Kernel SCM saga..

> (b) while I depend on the fact that if the SHA of an object matches, the > objects are the same, I generally try to avoid the reverse > dependency. It might be a valid point that you want to leave the door open to using a different (than SHA1) digest. (So this means you going to

Re: Kernel SCM saga..

Linus wrote: > In "git", you usually care about > the old contents too. True - in your case, you probably want the old contents so might as well dig them out as soon as it becomes convenient to have them. I was objecting to your claim that you _had_ to dig out the old contents to determine

Re: Kernel SCM saga..

Hi, On Fri, 8 Apr 2005, Linus Torvalds wrote: > Yes. Per-file history is expensive in git, because if the way it is > indexed. Things are indexed by tree and by changeset, and there are no > per-file indexes. > > You could create per-file _caches_ (*) on top of git if you wanted to make > it

Re: Kernel SCM saga..

Linus wrote: > (you need to remember to escape '%' > too when you do that ;). No - don't have to. Not if I don't mind giving fools that embed newlines in paths second class service. In my case, if I create a file named "foo\nbar", then backup and restore it, I end up with a restored file named

Re: Kernel SCM saga..

On Apr 8, 2005 4:52 PM, Roman Zippel <[EMAIL PROTECTED]> wrote: > The problem is you pay a price for this. There must be a reason developers > were adding another GB of memory just to run BK. > Preserving the complete merge history does indeed make repeated merges > simpler, but it builds up

Re: Kernel SCM saga..

Hi, On Fri, 8 Apr 2005, Linus Torvalds wrote: > Also, I suspect that BKCVS actually bothers to get more details out of a > BK tree than I cared about. People have pestered Larry about it, so BKCVS > exports a lot of the nitty-gritty (per-file comments etc) that just > doesn't actually _matter_,

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: > > > in order to avoid having to worry about special characters > > they are NUL-terminated) > > Would this be a possible alternative - newline terminated (convert any > newlines embedded in filenames to the 3 chars '%0A', and leave it as an > exercise

Re: Kernel SCM saga..

On Thu, Apr 07, 2005 at 12:30:18PM +0200, Matthias Andree wrote: > On Thu, 07 Apr 2005, Sergei Organov wrote: > > darcs? > > Close. Some things: > > 1. It's rather slow and quite CPU consuming and certainly I/O consuming >at times - I keep, to try it out,

Re: Kernel SCM saga..

Linus wrote: > If you want to have spaces > and newlines in your pathname, go wild. So long as there is only one pathname in a record, you don't need nul-terminators to be allow spaces in the name. The rest of the record is well known, so the pathname is just whatever is left after chomping off

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: > > I must be missing something here ... > > If the stat shows a possible change, then you shouldn't have to open the > original version to determine if it really changed - just compute the > SHA1 of the new file, and see if that changed from the

Re: Kernel SCM saga..

> in order to avoid having to worry about special characters > they are NUL-terminated) Would this be a possible alternative - newline terminated (convert any newlines embedded in filenames to the 3 chars '%0A', and leave it as an exercise to the reader to de-convert them.) Line formatted ASCII

Re: Kernel SCM saga..

Marcin wrote: > But what will impress you are either the price tag the > DB comes with or > the hardware it runs on :-) The payroll for the staffing to care and feed for these babies is often impressive as well. -- I won't rest till it's the best ...

Re: Kernel SCM saga..

Linus wrote: > then git will open have exactly _one_ > file (no searching, no messing around), which contains absolutely nothing > except for the compressed (and SHA1-signed) old contents of the file. It > obviously _has_ to do that, because in order to know whether you've > changed it, it

Re: Kernel SCM saga..

Linus wrote: > you need to reuse the same inode/dev numbers > (again - I didn't worry about portability, and filesystems where those > aren't stable are a "don't do that then") On filesystems that don't have a stable inode number, I use the md5sum of the full (relative to mount point) pathname

Re: Kernel SCM saga..

It seems that Tom Lord, the primary architect behind GNU Arch has recently published an open letter to Linus Torvalds. Because no open letter to Linus would be really open without an accompanying reference post on lkml, here it is:

Re: Kernel SCM saga..

Ok, this was literally screaming for a rebuttal! :-) > Arch isn't a sound example of software design. Quite contrary to the >

Re: Kernel SCM saga..

On Saturday April 9, [EMAIL PROTECTED] wrote: > On Sat, Apr 09, 2005 at 05:47:08PM +1000, Neil Brown wrote: > > On Saturday April 9, [EMAIL PROTECTED] wrote: > > > > > > I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 > > > files each) and 1.3s once the trees are cached

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote: > > On 2005-04-07, at 09:44, Jan Hudec wrote: > > > >I have looked at most systems currently available. I would suggest > >following for closer look on: > > > >1) GNU Arch/Bazaar. They use the same archive format, simple, have the > >

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 05:47:08PM +1000, Neil Brown wrote: > On Saturday April 9, [EMAIL PROTECTED] wrote: > > > > I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 > > files each) and 1.3s once the trees are cached locally. This is without > > comparing file contents,

Re: Kernel SCM saga..

On Saturday April 9, [EMAIL PROTECTED] wrote: > > I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 > files each) and 1.3s once the trees are cached locally. This is without > comparing file contents, just meta-data. And it takes 19.33s to compare > the file's md5 sums

Re: Kernel SCM saga..

On Fri, Apr 08, 2005 at 11:56:09AM -0700, Chris Wedgwood wrote: > On Fri, Apr 08, 2005 at 11:47:10AM -0700, Linus Torvalds wrote: > > > Don't use NFS for development. It sucks for BK too. > > Some times NFS is unavoidable. > > In the best case (see previous email wrt to only stat'ing the parent

Re: Kernel SCM saga..

On Fri, Apr 08, 2005 at 12:03:49PM -0700, Linus Torvalds wrote: > And if you do actively malicious things in your own directory, you get > what you deserve. It's actually _hard_ to try to fool git into believing a > file hasn't changed: you need to not only replace it with the exact same > file

Re: Kernel SCM saga..

On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: | Hello, | | Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter | where Linus Torvalds <[EMAIL PROTECTED]> told me that... | > | > | > On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote: | > > | > > Here's a partial solution. It

Re: Kernel SCM saga..

On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: | Hello, | | Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter | where Linus Torvalds [EMAIL PROTECTED] told me that... | | | On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote: | | Here's a partial solution. It does

Re: Kernel SCM saga..

On Fri, Apr 08, 2005 at 12:03:49PM -0700, Linus Torvalds wrote: And if you do actively malicious things in your own directory, you get what you deserve. It's actually _hard_ to try to fool git into believing a file hasn't changed: you need to not only replace it with the exact same file

Re: Kernel SCM saga..

On Fri, Apr 08, 2005 at 11:56:09AM -0700, Chris Wedgwood wrote: On Fri, Apr 08, 2005 at 11:47:10AM -0700, Linus Torvalds wrote: Don't use NFS for development. It sucks for BK too. Some times NFS is unavoidable. In the best case (see previous email wrt to only stat'ing the parent

Re: Kernel SCM saga..

On Saturday April 9, [EMAIL PROTECTED] wrote: I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 files each) and 1.3s once the trees are cached locally. This is without comparing file contents, just meta-data. And it takes 19.33s to compare the file's md5 sums once the

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 05:47:08PM +1000, Neil Brown wrote: On Saturday April 9, [EMAIL PROTECTED] wrote: I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 files each) and 1.3s once the trees are cached locally. This is without comparing file contents, just

Re: Kernel SCM saga..

On Sat, Apr 09, 2005 at 03:01:29 +0200, Marcin Dalecki wrote: On 2005-04-07, at 09:44, Jan Hudec wrote: I have looked at most systems currently available. I would suggest following for closer look on: 1) GNU Arch/Bazaar. They use the same archive format, simple, have the concepts

Re: Kernel SCM saga..

On Saturday April 9, [EMAIL PROTECTED] wrote: On Sat, Apr 09, 2005 at 05:47:08PM +1000, Neil Brown wrote: On Saturday April 9, [EMAIL PROTECTED] wrote: I've just checked, it takes 5.7s to compare 2.4.29{,-hf3} over NFS (13300 files each) and 1.3s once the trees are cached locally.

Re: Kernel SCM saga..

Ok, this was literally screaming for a rebuttal! :-) Arch isn't a sound example of software design. Quite contrary to the

Re: Kernel SCM saga..

It seems that Tom Lord, the primary architect behind GNU Arch has recently published an open letter to Linus Torvalds. Because no open letter to Linus would be really open without an accompanying reference post on lkml, here it is:

Re: Kernel SCM saga..

Linus wrote: you need to reuse the same inode/dev numbers (again - I didn't worry about portability, and filesystems where those aren't stable are a don't do that then) On filesystems that don't have a stable inode number, I use the md5sum of the full (relative to mount point) pathname as the

Re: Kernel SCM saga..

Linus wrote: then git will open have exactly _one_ file (no searching, no messing around), which contains absolutely nothing except for the compressed (and SHA1-signed) old contents of the file. It obviously _has_ to do that, because in order to know whether you've changed it, it needs to

Re: Kernel SCM saga..

Marcin wrote: But what will impress you are either the price tag the DB comes with or the hardware it runs on :-) The payroll for the staffing to care and feed for these babies is often impressive as well. -- I won't rest till it's the best ...

Re: Kernel SCM saga..

in order to avoid having to worry about special characters they are NUL-terminated) Would this be a possible alternative - newline terminated (convert any newlines embedded in filenames to the 3 chars '%0A', and leave it as an exercise to the reader to de-convert them.) Line formatted ASCII

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: I must be missing something here ... If the stat shows a possible change, then you shouldn't have to open the original version to determine if it really changed - just compute the SHA1 of the new file, and see if that changed from the original

Re: Kernel SCM saga..

Linus wrote: If you want to have spaces and newlines in your pathname, go wild. So long as there is only one pathname in a record, you don't need nul-terminators to be allow spaces in the name. The rest of the record is well known, so the pathname is just whatever is left after chomping off

Re: Kernel SCM saga..

On Thu, Apr 07, 2005 at 12:30:18PM +0200, Matthias Andree wrote: On Thu, 07 Apr 2005, Sergei Organov wrote: darcs? http://www.abridgegame.org/darcs/ Close. Some things: 1. It's rather slow and quite CPU consuming and certainly I/O consuming at times - I keep, to try it out, leafnode-2

Re: Kernel SCM saga..

On Sat, 9 Apr 2005, Paul Jackson wrote: in order to avoid having to worry about special characters they are NUL-terminated) Would this be a possible alternative - newline terminated (convert any newlines embedded in filenames to the 3 chars '%0A', and leave it as an exercise to the

Re: Kernel SCM saga..

Hi, On Fri, 8 Apr 2005, Linus Torvalds wrote: Also, I suspect that BKCVS actually bothers to get more details out of a BK tree than I cared about. People have pestered Larry about it, so BKCVS exports a lot of the nitty-gritty (per-file comments etc) that just doesn't actually _matter_, but

Re: Kernel SCM saga..

On Apr 8, 2005 4:52 PM, Roman Zippel [EMAIL PROTECTED] wrote: The problem is you pay a price for this. There must be a reason developers were adding another GB of memory just to run BK. Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex

  1   2   3   4   >