[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
vary.
> 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
guide).
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,
Arne
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
- singing a part of the history of free software -
http://infinite-hands.draketo.de
signature.asc
Description: This is a digitally signed message part.