Re: [darcs-users] Re: [BK] upgrade will be needed

Patrick McFarland
2005-02-19T09:19:10Z

[-- Attachment #1: Type: text/plain, Size: 5780 bytes --]

On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote:
> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
>
> The advantage it will provide is that it'll be compact and a backup will
> compress at best too. Small compressed tarballs compress very badly
> instead, it wouldn't be even comparable. Once the thing is very compact
> it has a better chance to fit in cache, and if it fits in cache
> extracting diffs from each file will be very fast. Once it'll be compact
> the cost of a changeset will be diminished allowing it to scale better
> too.

In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By
using it's super magical method, it represents how code is written and how it
changes (patch theory at its best). You can clearly see the direction code is
going, where it came from, and how it relates to other patches.

Sure, you can do this with RCS/SCCS style versioning, but whats the point? It
is inefficient, and backwards.

> Now it's true new disks are bigger, but they're not much faster, so if
> the size of the repository is much larger, it'll be much slower to
> checkout if it doesn't fit in cache. And if it's smaller it has better
> chances of fitting in cache too.

Thats all up to how the versioning system is written. Darcs developers are
working in a checkpoint system to allow you to just grab the newest stuff,
and automatically grab anything else you need, instead of just grabbing
everything. In the case of the darcs linux repo, no one wants to download 600
megs or so of changes.

> The thing is, RCS seems a space efficient format for storing patches,
> and it's efficient at extracting them too (plus it's textual so it's not
> going to get lost info even if something goes wrong).

It may not even be space efficient. Code ultimately is just code, and changes
ultimately are changes. RCS isn't magical, and its far from it. Infact, the
format darcs uses probably stores more code in less space, but don't quote me
on that.

> The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed.

The darcs repo which has the entire history since at least the start of 2.4
(iirc anyways) to *now* is around 600 to 700.

> My suggestion is to convert _all_ dozen thousand changesets to arch or
> SVN and then compare the size with CVS (also the compressed size is
> interesting for backups IMHO). Unfortunately I know nothing about darcs
> yet (except it eats quite some memory ;)

My suggestion is to convert _all_ dozen thousand changesets to darcs, and then
compare the size with CVS. And no, darcs doesn't eat that much memory for the
amount of work its doing. (And yes, they are working on that).

The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks, lets
switch to SVN or Arch!" thing everyone else in the known universe is doing.
BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the same
goes for SVN vs Arch vs Darcs).

(Start Generic BK Thread On LKML Rant)

Dear Everyone,

I think if Linus is happy with BK, he should stick with it. His opinion
ultimately trumps all of ours because he does all the hard maintainership
work, and we don't. The only guy that gets to bitch about how much a
versioning system sucks is the maintainer of a project (unless its CVS, then
all bets are off).

Linus has so far indicated that he likes BK, so the kernel hacking community
will be stuck using that for awhile. However, that doesn't stop the license
kiddies from coming out of the woodwork and mindlessly quoting the bad parts
of the BK license (which, yes, its non-free, but at this point, who gives a
shit).

IMO, yes, a non-free versioning system for the crown jewel of the FLOSS
community is a little... odd, but it was LInus's choice, and we now have to
respect it/deal with it.

Now, I did say above (in this thread) that darcs would be really awesome for
kernel hacking, especially since it's inherent support for multiple
branches[1] and the ability to send changes from each other around easily
would come in handy; however, darcs was not mature at the time of Linus's
decision (and many say it is still not mature enough), so if Linus had
actually chosen darcs, I (and other people here) would be now flaming him for
choosing a versioning system that wasn't mature.

Similarly, if he had chosen arch, everyone would have flamed him for choosing
a hard to use tool. With svn, he would have met flamage by the hands of it
being too much like cvs and not supporting arch/darcs style branch syncing.
And if he stayed with cvs, he would have been roasted over an open fire for
sticking with an out of date, useless, insane tool.

And if he chose anything else that I didn't previously mention, everyone would
have donned flame retardant suits and went into the fray over the fact that
no one has heard of that versioning system.

No matter what choice Linus would have made, he would have had some part of
the community pissed at him, so it is ultimately his choice on what to use
because hes the only one going to be happy with it.

[1] The Linux Kernel is looks like a forest instead of just a few branches.

(End Rant)

So, in summary, anti-BK posts on the lkml are retarded. Oh, and I apologize if
I've put any words in your mouth, Linus.

--
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]