Hello Miles, On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote: > Yeah, the basic way arch organizes its repository seems _far_ more sane > than the crazy way CVS (or BK) does, for a variety of reasons[*]. No > doubt there are certain usage patterns which stress it, but I think it > makes a lot more sense to use a layer of caching to take care of those, > rather than screwing up the underlying organization. > > [*] (a) Immutability of repository files (_massively_ good idea)
what is so important about never modifying the repo? Note that only the global changeset database and a few ,v files will be modified for each changeset, it's not like we're going to touch all the ,v files for each checkin. Touching the "modified" ,v files sounds a very minor overhead. And you can incremental backup the stuff with recursive diffing the repo too. AFIK all other SCM except arch and darcs always modify the repo, I never heard complains about it, as long as incremental backups are possible and they definitely are possible. > (b) Deals with tree-changes "naturally" (CVS-style ,v files are a > complete mess for anything except file-content changes) Certainly it's more complicated but I believe the end result will be a better on-disk format. Don't get me wrong, current disk format is great already for small projects, it's the simplest approach and it's very reliable, but I don't think the current on-disk it scales up to the l-k with reasonable performance. > (c) Directly corresponds to traditional diff 'n' patch, easy to > think about, no surprises Nobody is supposed to touch the repo with an editor anyway, all it matters is how fast the command works. And you'll be able to ask to the SCM "show me all changesets touching this file, or even ""this range" of the file"", in the last 2 years" and get an answer in dozen seconds like with cvsps today. even cvsps creates an huge cache, but it doesn't need to unpack >20000 tar.gz tarballs to create its cache. Feel free to prove me wrong and covert current kernel CVS to arch and see how big it grows unpacked ;). Anyway this is quickly going offtopic with l-k, so we should take it to darcs and arch lists. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
