arch 2.0 first source available (git related)

arch 2.0 first source available (git related)

[Thomas Lord]

The first source release and some very early documentation for Arch 2.0
("revc") is now ready!

        Web page: <http://www.seyza.com/>

        Source: <http://www.seyza.com/releases/revc-0.0x0.tar.gz>

        Source (tar bundle) SHA1:
		9c279f78e57a99d517ccf5b983960620ff6f2cf7

        Source (tar bundle) size: 1732018

Some highlights:  revc has only 10 core commands;  there are about 165
functions; the source code is literally about 14K lines and is closer to
10K lines if you subtract out non-code boilerplate.

User complaints about tla 1.x being addressed in revc:

inventory is too complicated -- but is drastically simplified (almost
  eliminated) in 2.0

we hate the funny filenames -- 2.0 requires only a single .revc
  directory and you aren't expected to edit any files there.  No more
  {arch}, {arch}/=tagging-method, or deeply nested project-tree logs

the namespace blows -- 2.0 allows just about any revision name that
  doesn't contain a slash character.  There is a moderate limit on the
  length of a revision name.

all this stuff about registering archives and making mirrors is hard to
learn -- and, in 2.0, it's all gone.  You can use rsync to mirror stuff,
  for starters.  And all archives are anonymous -- there's no longer any
  such thing as an archive name.

too much is too slow -- although the 2.0 code isn't especially optimized
  yet, it seems to be hella snappy.

2.0 is very much git influenced but it brings some (imo significant)
  improvements to the table.

-t

Re: arch 2.0 first source available (git related)

[Petr Baudis]

Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> 2.0 is very much git influenced but it brings some (imo significant)
>   improvements to the table.

Could you list some of the things interesting for us? What is the
benefit of a prereq graph compared to just having a single shared object
database? From the documentation, that's the only interesting thing I
noticed which is different from git (and things like artificially
limiting filename length to 256 characters).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..

Re: arch 2.0 first source available (git related)

[Thomas Lord]

On Sat, 2005-07-09 at 13:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > 2.0 is very much git influenced but it brings some (imo significant)
> >   improvements to the table.
> 
> Could you list some of the things interesting for us? What is the
> benefit of a prereq graph compared to just having a single shared object
> database? From the documentation, that's the only interesting thing I
> noticed which is different from git (and things like artificially
> limiting filename length to 256 characters).

Well, partly the statement about improvements was a hint to look
beyond the docs to the code but...

The prereq graph is, indeed, an improvement.  

It:

* speeds up and simplifies blob-db GC

* vastly improves the possibilities for archive integrity
  checking

* can be used for smart, streamy network mirroring of revisions

* allows people to commit the same tree multiple ways: e.g., 
  once optimizing access for users who frequently read incremental
  updates and a second time for users who only update at named
  releases

* helps make the system securable (current code isn't yet) against
  the possibility of multiple files with identical fingerprints but
  different contents in the same or related trees

* helps in a variety of ways when it comes time to make `revc'
  operable over a network -- committing to a remote archive.

Other advantageous (imo) changes from `git' not mentioned in the
original message:

* blobs do not have header lines

  Git blobs all begin with a line of text declaring the "type"
  and size of the blob.   That doesn't increase database 
  verifiability significantly and I found no use for the headers.
  Having the headers makes it needlessly complicated to translate
  a file to or from a blob.

  `revc' does not have blob headers.


* `revc' uses portable file formats

   In working dirs, `git' stores binary files which are 
   endian, word-size, and compiler-environment specific.

   `revc' stores some binary files too (for performance
   and simplicity reasons) but uses only portable formats.

* `revc' is shaping up into much cleaner and more portable code

   (at least compared to the last version of `git' I saw --
    which was extremely *lucid* code but not terribly
    clean and not even attempting to be portable.)

The list goes on and I don't promise to be picking the 
most interesting items from it according to anybody's
particular metric of "interesting".

revc -- probably "strange yet familiar" to git hackers,
-t

Re: arch 2.0 first source available (git related)

[Petr Baudis]

Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> The prereq graph is, indeed, an improvement.  
..snip..

But object retrieval can be potentially as much as linear to the depth
of the prereq graph, right? I don't think any of the benefits you listed
are worth the complication, and you can still do the reachability
analysis pretty easily. (And I think it takes the same number of
roundtrips when downloading from remote server?)

> Other advantageous (imo) changes from `git' not mentioned in the
> original message:
> 
> * blobs do not have header lines
> 
>   Git blobs all begin with a line of text declaring the "type"
>   and size of the blob.   That doesn't increase database 
>   verifiability significantly and I found no use for the headers.
>   Having the headers makes it needlessly complicated to translate
>   a file to or from a blob.
> 
>   `revc' does not have blob headers.

In git, this is crucial at least for distinguishing commits and tags.
I personally consider the verifiability boost useful.

> * `revc' uses portable file formats
> 
>    In working dirs, `git' stores binary files which are 
>    endian, word-size, and compiler-environment specific.
> 
>    `revc' stores some binary files too (for performance
>    and simplicity reasons) but uses only portable formats.

I think they are only word-size specific, and that should be no big
matter to resolve, shall anyone want to.

> * `revc' is shaping up into much cleaner and more portable code
> 
>    (at least compared to the last version of `git' I saw --
>     which was extremely *lucid* code but not terribly
>     clean and not even attempting to be portable.)

All right, the portability could be better. ;-)

Kind regards,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..

Re: arch 2.0 first source available (git related)

[Thomas Lord]

On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > The prereq graph is, indeed, an improvement.  
> ..snip..

> But object retrieval can be potentially as much as linear to the depth
> of the prereq graph, right? 

Potentially but not, by far, in the common case.

Moreover, that depth is an arbitrary parameter which user's can
freely vary -- that's part of the point.


> I don't think any of the benefits you listed
> are worth the complication, and you can still do the reachability
> analysis pretty easily. (And I think it takes the same number of
> roundtrips when downloading from remote server?)
> 

I don't agree that any complication is added.  I know that 
some complications are avoided with this approach.

-t

Re: arch 2.0 first source available (git related)

[Petr Baudis]

Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
> > Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
> > where Thomas Lord <lord@emf.net> told me that...
> > > The prereq graph is, indeed, an improvement.  
> > ..snip..
> 
> > But object retrieval can be potentially as much as linear to the depth
> > of the prereq graph, right? 
> 
> Potentially but not, by far, in the common case.
> 
> Moreover, that depth is an arbitrary parameter which user's can
> freely vary -- that's part of the point.

But if the depth will be less than that, won't the user end up with some
(plenty) of the objects duplicated?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..

Re: arch 2.0 first source available (git related)

[Thomas Lord]

On Tue, 2005-07-12 at 01:31 +0200, Petr Baudis wrote:

> But if the depth will be less than that, won't the user end up with some
> (plenty) of the objects duplicated?


Some, yes, many, no.   It's pretty easy to tune how many, afaict.

-t