lkml.org 
[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel SCM saga..
Roman Zippel wrote:

>
>
>Please show me how you would do a binary search with arch.
>
>I don't really like the arch model, it's far too restrictive and it's
>jumping through hoops to get to an acceptable speed.
>What I expect from a SCM is that it maintains both a version index of the
>directory structure and a version index of the individual files. Arch
>makes it especially painful to extract this data quickly. For the common
>cases it throws disk space at the problem and does a lot of caching, but
>there are still enough problems (e.g. annotate), which require scanning of
>lots of tarballs.
>
>bye, Roman
>
>
I'm not going to defend or attack arch since I haven't used it enough. I
will say that darcs largely does suffer from the same problem that you
describe since its fundamental unit of storage is individual patches
(though it avoids the tarball issue). This is why David Roundy has
indicated his intention of eventually having a per-file cache:
http://kerneltrap.org/mailarchive/1/message/24317/flat

You could then make the argument that if you have a per-file
representation of the history, why do you also need/want a per-patch
representation as the canonical format, but that's been argued plenty on
both the darcs and arch mailing lists and probably isn't worth going
into here.

-Tupshin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-09 03:32    [W:0.141 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site