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

[Pierce T. Wetter III]

But consider this comparison which applies to most current Arch users:

If you currently heavily use a revision library, Arch 2.0 will take

roughly the same (probably slightly less) storage and deliver

very similar functionality and performance.

So while we're talking about archives getting larger -- we're also 

talking about Arch's on-disk data structures shrinking.

 Ok, so what I think you're trying to say here is this:

   tla 1.0:

     local checkout:   1 revisions worth of disk space, plus additional overhead

     archive:                N revisions worth of disk space somewhat compressed using diff+tgz

                                      Getting to revision N means having all intervening N revisions accessible, plus

                                      enormous faith in your diff tool. 

     archive+revlibs:   N revisions worth of disk space compressed using tgz

                                     Getting to revision N means having all revisions between N and your oldest revlib.

  tla 2.0

     local checkout:  1 revisions worth of disk space, plus smaller amount of overhead

     archive:                _up to_ N revisions worth of disk space, each compressed with gzip. 

                                   Getting to revision N means having revision N accessible. 

     archive+revlibs: no longer necessary.              

 So lets say I join the "foobar" project at revision 234567. While somewhere, someone probably has all 234567 revisions, I need not keep that around for my local archive. I can branch my archive off at 234565 and only have a couple of revisions around. (I'm making assumptions here, but I think they're good ones). 

If the revc version supports any sort of aliasing, its possible that it might even be built to retrieve revisions as needed from the "master" archive. 

 So 2.0 would use _less_ space on a typical developers machine, but more space on any central repository assuming the central repository didn't have any revlibs. If the central repository had some revlibs, then the new version now uses _less_ space. 

 Hmmm... Ok, so tla started as sort of a glorified version of the "tar everything up and save it to an new directory, while incrementing the version number" school of version control. It has its appeal because its the kind of thing one might use in ones own directories. Then a bunch of structures got added, and now it seems like tla is coming full circle and going back down that pathway. 

  Not that I disagree with the direction, I just think its interesting. The real issue with the "tar" method of version control is having multiple developers, if 2.0 makes that work in an easy transparent fashion, I think it makes a lot of sense and it might make it easier to explain to newbies. 

 "See, tla lets you just duplicate a directory on your hard disk when you need to go off and do something. When you want to push those changes back, or pull some changes other people have made, you just ask tla and it will figure out where the problems are." 

 Version control as "merge tool + metadata". Simple and clean... 

 Pierce