From: Thomas Lord <hidden> Date: 2016-06-15 22:42:01
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:01
Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
where Thomas Lord [off-list ref] 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..
From: Thomas Lord <hidden> Date: 2016-06-15 22:42:01
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 [off-list ref] told me that...
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:01
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord [off-list ref] 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..
From: Thomas Lord <hidden> Date: 2016-06-15 22:42:01
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 [off-list ref] told me that...
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:01
Dear diary, on Mon, Jul 11, 2005 at 11:36:56PM CEST, I got a letter
where Thomas Lord [off-list ref] told me that...
On Mon, 2005-07-11 at 21:39 +0200, Petr Baudis wrote:
quoted
Dear diary, on Sat, Jul 09, 2005 at 04:20:13PM CEST, I got a letter
where Thomas Lord [off-list ref] told me that...
quoted
The prereq graph is, indeed, an improvement.
..snip..
quoted
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..