What is your preferred VCS?
in [ADA]
|
From: Thomas Løcke on 30 Jul 2010 01:47 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 30 Jul 2010 03:17 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 30 Jul 2010 03:32 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 30 Jul 2010 03:41 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 30 Jul 2010 07:05
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. |