bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revision control


From: Arne Babenhauserheide
Subject: Re: Revision control
Date: Wed, 11 Jun 2008 10:02:33 +0200
User-agent: KMail/1.9.9

Am Dienstag 10 Juni 2008 23:59:36 schrieb olafBuddenhagen@gmx.net:
> > [...] and because of some glitches like having to garbage collect
> > regularly instead of having a lean implementation in the first place.
>
> Again, this is not a glitch, but a conscious decision -- and a brilliant
> one at that IMHO. I mentioned only some of the many advantages of this
> approach.

That's also a way to put it. 

Still it's inconvenient for me to have to remember to repack the repository 
all the time to avoid having it eat all my diskspace. 

And it is inconvenient, that when you just repacked the project I am 
following, but you didn't garbage collect for a month or so, I have to access 
the pack from the whole month in order to get the last few changes. 

If at some time the repository grows too big and you didn't ever gc before, I 
will have to access the whole project history to just get the few changes you 
did after I last pulled your code. 

And garbage collecting all the time destroys its advantage, as it will just 
create as many packs as you have revisions (as far as I understand it). 


> A revision control system is not a file system though. And running a
> filesystem on it is not exactly the common use case... Certainly not
> what we want to do with the Hurd repository.

Why not? 

Having a completely version controlled filesystem is something I'd love to 
have. 

I don't only use Mercurial for code, but also for my websites and for every 
text I write. 

And I could well imagine a Hurd filesystem server which uses Mercurial as 
backend, so every single change in a file gets recorded and can be reversed 
at any time. 


> It's funny that you quote this passage: It fully supports my argument
> that you need to understand the fundamentals -- much better than I could
> ever argue it myself :-)
>
> I wonder whether you were aware, while quoting it, how perfectly it fits
> git...

Yes. 

Even more I knew, though, that learning the fundamentals and what they mean to 
your workflow is far easier in Mercurial, and that it helps you to know them, 
but you don't have to. 

From my experience, Mercurial wouldn't surprise me, even if I didn't know the 
fundamentals (apart from 
- "I commit my own work locally. To get changes from others I pull them. To 
provide my changes back I push them"
), because its interface is designed for being easy to learn and easy to use. 


> > 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).
>
> Except if I don't know Python...

Then you simply invoke the bare mercurial commands without convenience 
scripts. 

Different from git, you can also look far deeper by using the python shell, 
though. 
You can get every single function Mercurial uses and call it individually. 

I don't do that, though, since I didn't ever have the need to do so (I just 
now confirmed that it is possible and quite simple). 


> And that is only one of the many many reasons why libraries are usually
> inferior to the traditional UNIX approach of reusing code by invoking
> other processes.

Now we're in a completely different field :) 

If you say "the basic design of Mercurial is inferior, regardless to its 
usability", I can't say if you're right or wrong. 

I am studying physics, so I see informatics mostly as providing tools I want 
to use (and allowing me to write these tools myself), but I don't know enough 
of the advantages of different structures in software design to be able to 
comment. 

And I use the free tool which works best for me (or of which I expect that it 
will work best, as in the case of the Hurd). 

I see what works, and I read up on some basics which interest me, but I can't 
comment on "advantages of invoking processes instead of using libraries". 

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]