Re: Revision control

[Arne Babenhauserheide]

Am Samstag 07 Juni 2008 17:54:46 schrieb olafBuddenhagen@gmx.net:
> >     ... And, in my opinion, that contributes to the ``usefulness''
> >     of knowing Git.  Isn't the intent for Hurd is to be based on
> >     ``very simple yet powerful ideas''?  And to provide layered
> >     (rather than monolithic) implementation of its features?
>
> Indeed, what I consider most interesting about the Hurd is that it
> extends UNIX mechanisms in a way making the UNIX principles more
> generally applicable. It seems to me that anyone fully appreciating the
> advantages of Hurd must also appreciate UNIX concepts, and thus git...

I do appreciate UNIX mechanisms, but I don't completely appreciate git because 
of its weak usability, because it isn't really split that well (see 'git 
checkout') and because of some glitches like having to garbage collect 
regularly instead of having a lean implementation in the first place. 

Would you use a file system you have to repack regularly? Just think about 
what would happen, if we build a server on top of git, which used it as 
filesystem backend. 
With Mercurial as backend it would just work. 


I don't see your claim that "If you appreciate Hurd you must appreciate git". 
And even if you appreciate some aspects of the design of git, you don't have 
to appreciate its usability (the usability is what you get in the end). 


And while Mercurial doesn't spread its binary files around like git, it builds 
on simple concepts which can even be explained to nontechnical people, and 
which can be accessed individually. 

This was one of the things which helped to convince me, that Mercurial is the 
right choice for me: 

"""Unlike many revision control systems, the concepts upon which Mercurial is 
built are simple enough that it’s easy to understand how the software really 
works. Knowing this certainly isn’t necessary, but I find it useful to have 
a “mental model” of what’s going on. 

This understanding gives me confidence that Mercurial has been carefully 
designed to be both safe and efficient. And just as importantly, if it’s easy 
for me to retain a good idea of what the software is doing when I perform a 
revision control task, I’m less likely to be surprised by its behaviour. 

In this chapter, we’ll initially cover the core concepts behind Mercurial’s 
design, then continue to discuss some of the interesting details of its 
implementation."""
- http://hgbook.red-bean.com/hgbookch4.html#x8-640004


And you can easily access all the core functionality of Mercurial using either 
the default Python shell (just do "from mercurial import <module>", or 
advanced shells like ipython (which I very much appreciate). 

With ipython you can work with it at least as comfortable as with basic 
command line tools. 

I just looked into the source code, and it is split into seperate modules 
which do one task (as I expected, but what I wanted to verify), and most 
additional functionality is inside extensions and can be activated when it is 
needed. 


Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.