Re: [Gnu-arch-users] GNU Arch 2.0 -- first source

[Matteo Settenvini]

I hope not to say a lot of bullshit ( :duck!: ), because I'm quite new
to the world of gnu arch, so feel free to slash back: I'm just trying to
understand, not to flame. Be patient :-)

Thomas Lord ha scritto:
> On Sun, 2005-07-10 at 17:45 +0400, nick wrote:
> 
> 
>> [...]
> 
> Crudely put, the main answer as to why revc is more space hungry is
> that, at the scales of use cases of greatest interest, nobody is
> (sanely) keeping score about this difference in space consumption.
> 
> I'll say it differently: a modern revision control system can and
> probably should gleefully consume local disk space at rates 10x..1000x
> greater than, for example, CVS if, in return for doing so, user benefits
> can be realized.

This is usually fine for a centralized SCM like git. But how about
normal users that have not-so-much disk space on their desktop, and want
to sync to, say, kernel sources often? I don't want to go out to buy a
new hard disk every once in a while to work on a project, even if
storage nowadays doesn't cost much. This is also a problem of git, afaik.

In contrast, as a "desktop" user, I've a lot of broadwidth to waste,
since broadband costs are just a monthly forfait for me (just to say
that this scenario is different from the one explained in "How Arch Works").

revc, as tla, would be distributed, and you're likely to have a lot of
local branches and revisions. I _liked_ small archives; I liked the way
you could mirror them on a USB key, for example, or regularly backup
them on cd, the whole of them.

It isn't also true that using changesets necessarily hungers for more
bandwidth. I don't care waiting a little longer for a repository to be
fetched and the changesets applied from the last cached revision; it
happens only when doing the first "checkout" (using a CVS word). Then
this means less bandwidth usage to get further patches: say that I don't
need just a specific revision, but I need to inspect all the differences
between a series of them? I need all the patches. And this is often the
case, since in many projects you want to be sure that no patch goes in
without a review, so you "replay" them one by one.

I think that a possible solution to reduce tla bandwidth consumption is
a "server" that applies changesets locally before sending a revision
through network. And, at the same time, this is exactly what tla is
trying to avoid. :-) Hence the revision libraries, and cached revisions,
if I understood that correctly.

These are obviously my own opinions. I also feel that because git is in
use by kernel developers, it doesn't automatically makes that "in" and
everything else "out". revc should get better and innovative, not just
another between a forest of doujinshi. After all, kernel developers are
unlikely to switch off from git at this point of development, so they're
not a "target" (using market-speak).

In the end, I chose tla over cvs and sv and git because that gives me
those "user benefits" you're speaking about. Decentralized development,
some (but contained) space consumption in exchange of relative speed,
easeness in applying and exchanging changesets between developers, nice
merge features and (believe it or not) a nice, if complex at times, user
interface.

> 
> Even at that stepped-up rate of space consumption, the cost-of-operation
> of a modern system will still be less than the relative cost for
> operating CVS in it's heyday.

That's for sure. It's hard to make something perform worse than cvs.
Please don't take the nag as an example to show how much your horse is
good. ;-)

> 
> tla revision libraries are a good hint that this analysis is right:
> afaict, plenty of users like me have revlibs that just grow and grow
> and include essentially every revision i've got archived or mirrored.
> Revision libraries cost more per revision than revc commits yet provide
> pretty much the same benefit.

And it is good because users at this point can choose not to use them if
they don't want to. Can't we continue to strife towards that wonderful
"the-user-can-always-choose-what-he-wants" philosophy?

Or maybe (probably) it's me that don't understand at all about revision
libraries; I simply don't regard them as so important. The documentation
is a little bit foggy about them, can someone elaborate on their
importance? Cached revisions worked fine for me up until now.

> 
> Other good hints are monotone and git -- we crossed the line at which
> sub-file delta-compression ceases to be important in the common cases
> some time ago.
> 
> -t
>

I wouldn't put the word "end" to it so soon... if history teaches that
storage grows almost exponentially, it also says that users ask for more
space factorially.

Anyway, thanks for your wonderful piece of work. Whatever your
direction, you've proven to take the right decision most of times.
I'll probably follow, but I'd like to be a little bit more sure that
this path is really the Zen about SCM.

Regards,
-- 
Matteo Settenvini
FSF Associated Member
Email : address@hidden


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++
P?>++ L+++>$ E+>+++ W+++ N++ o?
w--- O- M++ PS++ PE- Y+>++
PGP+++ t+ 5 X- R tv-- b+++ DI+
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------

signature.asc
Description: OpenPGP digital signature