gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Linus Torvalds <address@hidden> Re: log-buf-len dyn


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] Linus Torvalds <address@hidden> Re: log-buf-len dynamic
Date: Thu, 2 Oct 2003 16:21:52 +0100
User-agent: Mutt/1.5.4i

On Thu, Oct 02, 2003 at 05:41:46PM +0300, Momchil Velikov wrote:
> 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. 

There's a whole pile of ancillary tools that want writing for
tla. This is only a small part of the list.

I've no idea how many such tools bk bundles as part of the package.

> 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.

Arch archives are just tarballs with no real metadata, so this doesn't
apply.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

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