[Top][All Lists]

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

Re: Mercurial vs. git

From: Arne Babenhauserheide
Subject: Re: Mercurial vs. git
Date: Wed, 28 Oct 2009 20:03:26 +0100
User-agent: KMail/1.12.2 (Linux/2.6.30-gentoo-r5; KDE/4.3.2; x86_64; ; )

Am Sonntag, 25. Oktober 2009 10:54:44 schrieb olafBuddenhagen@gmx.net:
> > If you don't have to integrate hundreds of branches, then there's no
> > merit in learning how to do that efficiently - so it isn't efficient
> > to have to learn background for that before being able to use the
> > system efficiently for other stuff.
> The point is that there is hardly anything you need to learn for
> specific tasks like integrating many branches -- once you understand the
> basics, most specific tasks become trivial!

That's not really a specific task to me, but basic operation... 
In mercurial it's 
"hg merge <branch name>" for named branches or "hg merge <revision>" for 
unnamed ones - maybe with "hg pull <source>" or "hg import <patch>" to get 
them into your local clone. 

> You can't measure the efficiency of VCS usage by "the time spent using
> it". That just doesn't reflect reality. "Managing history", and other
> VCS usage, is not a separate task -- using the VCS is part of the
> programming workflow. Efficient VCS usage is about being able to perform
> my *programming* work in the most efficient manner.

Then lets state it more precisely: 

"The time spent using it" has to be changed to "the time overhead created by 
the time spent in the version tracking part of the work". 

"Jumping back in history" is a version tracking action, as is merging, 
branching, etc, so it adds to the version tracking overhead. 

To be really fair, you have to substract the programming time you save because 
you can move more freely in history. That way you get a ┬▒time which is the 
part of your programming spent with version tracking. 

You can even go to defining VCS actions. Having a certain VCS action at your 
disposal can save you programming time. That time reduces the overall VCS 
overhead. Everytime you do a VCS action, you need a certain amount of time. 
That time adds to the VCS overhead. Then you add all the factors I mentioned 
earlier (learning time, ...) and add everything over the time span you're 
likely to use the tool (10-30 years?). 

The VCS overhead can easily become negative this way, but heck, that's what 
good tools are about :) 

It should be true for Git and Mercurial - I don't know how much teh degrees 

> It's not about what you *have* to do, but about what you *can* do. As I
> already said at the setout, it is perfectly possible to perform all
> tasks with only a handful of fixed workflows, and with VCS knowlegde
> limited only to these few workflows. 

Did you read my guide? That's pretty much what  say in the middle of the guide 
"now you can do about everything. All that follows is about convenience - and 
that's good". 

> (In fact, even most git users seem
> to work that way -- which is a very sad situation indeed :-( )

But that really defeats everything you write later about efficient workflows. 

In Mercurial people routinely jump back and forth, use feature clones and much 
more, because it is really easy and fast - you'll notice, that it's in the 
basic workflows for which you don't need any extensions (the ones in the 

A powerful tool is only useful to a group, if most people use its power - and 
being easy to learn increases the number of people who can access the power. 

(most people are lazy and generally don't dive deep, and the required startup 
learning time reduces the number of people who learn the deeper flow; I wonder 
if it's an exponential function like the one in statistical physics: 
number_in_a_state = N_0 * exp(-Energy_to_reach_the_next_step*num_steps)

For VCS: 
people with number of tricks mastered = 
= exp(-Energy per trick * number of tricks)

Since the energy per trick isn't linear, these will somehow group. If there 
are many easy to learn tricks, most people will know many tricks. If most 
tricks require a startup time investment, most people won't know any tricks 
and some will know almost all. 

Only speculation and possibly disallowed analogies, though ;) 

Best wishes, 

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -

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

reply via email to

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