[ECOS] DVCS choice

[ECOS] DVCS choice

[Øyvind Harboe]

Switching to DVCS is the hard bit.

Whether to choose git or hg (I don't think there
are others in the running still) is only hard because
they are so similar.

If the "wrong" DVCS is chosen for eCos today, then
presumably switching will be much easier than the
switch from CVS to DVCS.

Here is a relatively famous web site:

http://whygitisbetterthanx.com/

I prefer git because I have to learn it anyway(Linux work)
and because I believe it has brighter future than hg.

Learning git PLUS hg is a steeper learning curve...


-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: DVCS choice

[Øyvind Harboe]

Perhaps a choice between git & hg is unecessary?

There are conversion tools between git/hg so the question
what to present to end users and what maintainers
use can be two different version control systems. There
could even be official git & hg mirrors regardless of
"official" choice.

You can even push/pull to/from git/hg with any combination
of client & server. Spooky! Bet there are some hitches
when you actually try that at home!

Certainly if someone has a strict policy of not using X
on the client, then there is nothing that stops them from
converting to their preferred DVCS client.

I just converted from mercurial to git on my laptop and
it took ~10-20 minutes. Used hg-fast-export.

I couldn't find any branches in the git repository, but I
suppose that there weren't any in the mercurial repository
either.

git checkout afterwards took 10 seconds or so. DVCS
is insanely much faster than CVS for those operations...

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: DVCS choice

[Alex Schuilenburg]

Øyvind Harboe wrote:
> Perhaps a choice between git & hg is unecessary?
>
> There are conversion tools between git/hg so the question
> what to present to end users and what maintainers
> use can be two different version control systems. There
> could even be official git & hg mirrors regardless of
> "official" choice.
>   
You still need to publish some way for users to be able to contribute
easily, and having multiple options is just going to confuse the average
Joe.  Besides, you still need somewhere for contributions to be collated
and that has to be based on something.

Anyway, I don't see a need to present multiple DRCS repositories.  You
can push/pull hg into git (http://hg-git.github.com/) and I expect
vice-versa, so there is little point of mirrors in different formats
IMHO.  You even say so below ;-)

> You can even push/pull to/from git/hg with any combination
> of client & server. Spooky! Bet there are some hitches
> when you actually try that at home!
>   
None that I have come across, but then I have only been playing with the
basic operations like push, pull, commit, revert, rollback, tag, branch,
merge.  I expect an octopus merge between different DRSC systems will be
quite interesting ;-)

> Certainly if someone has a strict policy of not using X
> on the client, then there is nothing that stops them from
> converting to their preferred DVCS client.
>
> I just converted from mercurial to git on my laptop and
> it took ~10-20 minutes. Used hg-fast-export.
>   
Around 7 minutes on our main server, and then just for the hell of it, I
converted the git repo back to hg to see if it came back the same.  diff
-r -q -x .hg ... said it did :-)

> I couldn't find any branches in the git repository, but I
> suppose that there weren't any in the mercurial repository
> either.
>   
Correct, there were none.  The three CVS branches were just cloned.  I
could have made the 2.0 and 3..0 releases into branches and just cloned
the flash_v2 branch, but then the conversion would have been a little
bit more painful since most of the release changes were just duplicated
into the trunk rather than actually being merged after the release.  If
there was a clear merge point in the CVS repo, I would have done it -
there looked like a couple which I tried, but there were just too many
conflicts resulting from the duplicate checkins.  My guess is the
maintainers were being paranoid about forgetting to pull in release
changes into the trunk so they made duplicate checkins as they went.

Also little point in spending any effort "fixing" the repo to reflect
what might have happened if a DRCS was used - we need something moving
forward that preserves the history, which we now have.

> git checkout afterwards took 10 seconds or so. DVCS
> is insanely much faster than CVS for those operations...
>
>   
Indeed. Here are some real hg times from our main server.

bash% time hg clone ecos ecos-test-with-update
updating working directory
8085 files updated, 0 files merged, 0 files removed, 0 files unresolved

real    0m8.655s
user    0m5.672s
sys     0m2.293s
bash% time hg clone -U ecos ecos-test-without-update

real    0m1.777s
user    0m0.651s
sys     0m1.103s
bash% time hg -R ecos-test-without-update update
8085 files updated, 0 files merged, 0 files removed, 0 files unresolved

real    0m7.010s
user    0m5.579s
sys     0m1.402s
bash%

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] DVCS choice

[Alex Schuilenburg]

Øyvind Harboe wrote:
> Switching to DVCS is the hard bit.
>
> Whether to choose git or hg (I don't think there
> are others in the running still) is only hard because
> they are so similar.
>
> If the "wrong" DVCS is chosen for eCos today, then
> presumably switching will be much easier than the
> switch from CVS to DVCS.
>   
I don't believe either is the "wrong" choice.  Choosing between the two
is like choosing a car IMHO.  Either choice will get you from A to B.

> Here is a relatively famous web site:
>
> http://whygitisbetterthanx.com/
>   
Odd that this is the first I have seen it then ;-). 

However, I disagree with a lot of the reasons and comparisons given, and
a couple of them are just plain wrong. I have used git and hg, rather
than just read about them. For example, local branching is cheap in both
bzr and hg as well. So when I see the first item in the list just a
plain wrong, I tend to discount the rest as FUD.  There are plenty of
objective and technical evaluations with measurements out there.  Some
say git, some say hg.  Very few I have seen say bzr.  That website adds
nothing to the discussion other than stating the personal preference of
a Linux/Linus fan.

IMHO it just comes down to if you want a reliable family sedan which the
kids can enjoy and just goes when you turn the key, or something a bit
more sportier which could end up in a ditch and needs a bit of
maintenance now and again.  For example I find it interesting that git
needs TLC occasionally to help keep the size of its repos down and keep
the speed of its operations fast.  hg just works and needs no maintenance.

> I prefer git because I have to learn it anyway(Linux work)
> and because I believe it has brighter future than hg.
>   
Why?  Because this is the choice of Linux fans because Linus wrote it,
or is there some substance to your belief?

I don't believe there ever will be a clear winner and IMHO anyone who
suggests otherwise has not used the other in earnest.  Even Linus admits
hg is OK (but he prefers git because he wrote it).

Sure, git has a bigger fan base in open source because of its
association with Linux and Linus and the number of kernel developers
that use it regularly, but that does not make it right nor give any
guarantees.  It is like saying Linux sucks because there are more
Windows users out there. However most Linux kernel developers tend to be
CLI based power geeks, like most of the eCos maintainers. IMHO a
solution that potentially addresses a wider audience, yet still gives
the CLI geeks what they need, is the better one.

hg and git started at roughly the same time, but hg has more and better
GUI support and integration, and its documentation is a lot more
structured and easier to read than git.  Sure, git can catch up, just as
hg can with octopus merges etc (or whatever else tickles your fancy).


> Learning git PLUS hg is a steeper learning curve...
>   
Is http://mercurial.selenic.com/wiki/CvsInfo that hard to comprehend if
you come from a CVS world?

It only becomes harder if you are a power-freak and want to do octopus
merges and other operations that 99.9% of the remaining users will never
do.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] DVCS choice

[Alex Schuilenburg]

Øyvind Harboe wrote:
> I prefer git because I have to learn it anyway(Linux work)
>   
Believe me, if you know git, picking up hg is a walk in the park.  It
really is a no-brainer.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] DVCS choice

[Øyvind Harboe]

On Tue, Oct 13, 2009 at 12:19 AM, Alex Schuilenburg
<alexs@ecoscentric.com> wrote:
> Øyvind Harboe wrote:
>> I prefer git because I have to learn it anyway(Linux work)
>>
> Believe me, if you know git, picking up hg is a walk in the park.  It
> really is a no-brainer.

See my other post. My problem with mercurial is that it is currently
yet another version control system.

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss