* arch 2.0 first source available (git related)
@ 2005-07-09 0:12 Thomas Lord
2005-07-09 11:39 ` Petr Baudis
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Lord @ 2005-07-09 0:12 UTC (permalink / raw
To: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-09 0:12 arch 2.0 first source available (git related) Thomas Lord
@ 2005-07-09 11:39 ` Petr Baudis
2005-07-09 14:20 ` Thomas Lord
0 siblings, 1 reply; 7+ messages in thread
From: Petr Baudis @ 2005-07-09 11:39 UTC (permalink / raw
To: Thomas Lord; +Cc: git
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..
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-09 11:39 ` Petr Baudis
@ 2005-07-09 14:20 ` Thomas Lord
2005-07-11 19:39 ` Petr Baudis
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Lord @ 2005-07-09 14:20 UTC (permalink / raw
To: Petr Baudis; +Cc: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-09 14:20 ` Thomas Lord
@ 2005-07-11 19:39 ` Petr Baudis
2005-07-11 21:36 ` Thomas Lord
0 siblings, 1 reply; 7+ messages in thread
From: Petr Baudis @ 2005-07-11 19:39 UTC (permalink / raw
To: Thomas Lord; +Cc: git
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..
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-11 19:39 ` Petr Baudis
@ 2005-07-11 21:36 ` Thomas Lord
2005-07-11 23:31 ` Petr Baudis
0 siblings, 1 reply; 7+ messages in thread
From: Thomas Lord @ 2005-07-11 21:36 UTC (permalink / raw
To: Petr Baudis; +Cc: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-11 21:36 ` Thomas Lord
@ 2005-07-11 23:31 ` Petr Baudis
2005-07-12 0:05 ` Thomas Lord
0 siblings, 1 reply; 7+ messages in thread
From: Petr Baudis @ 2005-07-11 23:31 UTC (permalink / raw
To: Thomas Lord; +Cc: git
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..
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arch 2.0 first source available (git related)
2005-07-11 23:31 ` Petr Baudis
@ 2005-07-12 0:05 ` Thomas Lord
0 siblings, 0 replies; 7+ messages in thread
From: Thomas Lord @ 2005-07-12 0:05 UTC (permalink / raw
To: Petr Baudis; +Cc: git
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-07-12 0:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-09 0:12 arch 2.0 first source available (git related) Thomas Lord
2005-07-09 11:39 ` Petr Baudis
2005-07-09 14:20 ` Thomas Lord
2005-07-11 19:39 ` Petr Baudis
2005-07-11 21:36 ` Thomas Lord
2005-07-11 23:31 ` Petr Baudis
2005-07-12 0:05 ` Thomas Lord
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).