From: Thomas Løcke on
On 2010-07-30 04:27, deadlyhead wrote:
> And those who like Git: Fast, cheap and easy... for some reason that
> seems _very_ Linus Torvalds-ish. :-) Still, Perl scripts
> intermingled with C? Perhaps I just need to get over that. I'll read
> over the Why Git is Better... site. It _does_ seem easy to try out.
> Perhaps I'll be able to look the other way when it comes to
> aesthetics.


As far as I know, that was only true back in the very early days of Git.

Git is written in plain old C.

I just took a quick look at the source for Git 1.7.2.1, and I couldn't
find anything that looked messy, ugly or Perl'ish. It's just plain C,
and very good C at that, IMHO.

Why not just grab the source yourself and look it over?

http://kernel.org/pub/software/scm/git/git-1.7.2.1.tar.gz

Maybe there's a grand Ada project sitting here, just waiting to get
done? An Ada powered Git! :D

--
Regards,
Thomas L�cke

Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
From: Timo Warns on
You may also be interested in the analysis of Google on Git vs. Mercurial:
http://code.google.com/p/support/wiki/DVCSAnalysis

I personally prefer Mercurial over Git. It has all the features I need, is
stable, and has a more gradual learning curve than Git.
From: Georg Bauhaus on
On 7/30/10 4:27 AM, deadlyhead wrote:

> For those who like Monotone: is using a "real database" really that
> much of advantage? I'm a bit leery of such an opaque system being
> used to save my patches. Having physical file-system access to
> changes makes _me_ feel a bit more secure,

I find dumping and importing of Monotone's sqlite databases reassuring.
(It never felt equally promising when something went wrong in darcs's file
system storage area...)

Output of the .dump command is SQL text. Example first lines of
a repository, copied from a real repository:

BEGIN TRANSACTION;
CREATE TABLE files
(
id primary key, -- strong hash of file contents
data not null -- compressed contents of a file
);
INSERT INTO "files" VALUES(X'8C9C5E5179290FF93F3024391C1FAACB1BD393EE',X'1F8B08000000000000FFAD595B6F134B127EE757B
4FCB0198BC4109ECEC231524808EBDD00511C402B8446ED71C79E3D76B777A6872452B4BF7...

Easy backup; 7bit network transport works; file system independence;
explicit relations;...
An email, secured as necessary, stuffed with a dumped repository
will serve as permanent file storage for smaller projects...

I guess that everything to be had via SQL from Monotone's ER model
is not that easily had from a journalling file system. Even when
the hand full of tools like ls, awk, and some VC specific programs
can be used to create an RDMS, will it be simpler or more secure
than some industry standard data base?
From: Maciej Sobczak on
On 30 Lip, 04:27, deadlyhead <deadlyh...(a)gmail.com> wrote:

> (I'm not particularly a fan of
> Python, which is why I haven't looked at Mercurial closely, either.)
[...]

> Still, Perl scripts
> intermingled with C?

I think that you are too much focused on the implementation details.
VCS is a *tool*. Are you going to fork it and continue its development
yourself or just, you know,... USE it?
I don't understand your focus, really.

Just in case you decide to tame your bias, this is something you might
want to read:

http://progit.org/book/

It is not a comparison of existing tools (if you are interested in
comparisons, you will never take any decision before retirement), it
is a manual on how to use Git. This book has vastly improved my
efficiency and expanded my understanding on various development
workflows, you might like it as well.

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4
From: Ludovic Brenta on
deadlyhead <deadlyhead(a)gmail.com> writes on comp.lang.ada:
> From this small-but-elite sample, it seems like Monotone and Git are
> the routes to check out more deeply, if for no other reasons than
> speed and code security. Developers seem to trust them!

That is also my conclusion. I prefer Monotone.

> For those who like Monotone: is using a "real database" really that
> much of advantage? I'm a bit leery of such an opaque system being
> used to save my patches. Having physical file-system access to
> changes makes _me_ feel a bit more secure, and is something that I
> really like about GNU Arch. Is it the speed that makes it good? Or
> collision detection? I'm just curious; I've never had problems in
> those areas before, so I'm a bit insensitive.

I like the fact that a database is a single file.

I like the fact that this single file is outside working trees; I can
thus safely "rm -rf" a working tree without losing the database. Also,
I share my databases between multiple working trees.

I like to be able to use the SQLite command-line interface to run SQL
queries on it; this is much easier than a specialized set pf VC-specific
commands if you need to get at the data from outside Monotone. In fact,
Monotone has the "mtn db execute <SQL_Statement>" for that purpose.

I like the attitude of the Monotone developers. They have an extensive
test suite which they run systematically and extend with each new
feature. Similarly the excellent documentation is in sync with the code
base. While git started out as a quick hack developed over a couple of
days, monotone did the Right Thing from the onset, fosusing on
performance only afterwards (and performance is very good nowadays).

> And those who like Git: Fast, cheap and easy...

Personally, I do not find git easy at all. Monotone is much easier to
understand and use IMHO. The sheer number of commands and options in
git is daunting; there are redundancies, overlaps and idiosyncrasies in
this command set (e.g. does anyone on comp.lang.ada understand the
subtle difference between git-merge-base and git-show-branch
--merge-base ?)

--
Ludovic Brenta.