Deciding between Git/Mercurial

Deciding between Git/Mercurial

[Anteru]

Hi,

I'm currently evaluating DVCS for a project, and we're at a point where
it comes down to either Mercurial or Git. Right now, I'm advocating for
Git, while my co-workers like Mercurial, so I'd like to provide some
good arguments in favor of git. Unfortunately, I'm not a git expert, so
I hope I can get some help here ...

First of all, what's the matter with git and Windows, is there some
long-term commitment to make git work on Windows as well as on Linux?
I'm using msysgit on Windows, and personally I'm happy with it, but my
co-workers constantly nag that Mercurial has superior portability ...

Mercurial's revision number system: With git, I get an SHA1 hash for
every commit, but it's not possible to see whether Hash1 is newer than
Hash2, while Mecurial also adds a running number to each commit. What's
the rationale behind this decision for git, and is it possible to
emulate Mercurial's behavior somehow?

Integration into tools: We're using Trac currently, which also has a
nice binding to Mercurial (well, obviously easy to do as Mercurial is
written in Python, just as Trac itself), while the git support is in
development and looks quite alpha'ish. Do you plan to make it easier to
integrate git with other tools by providing bindings to other languages,
or is this a low-priority issue?

So far, my key arguments are that git is more robust (more projects
using it, larger developer base), of course git's excellent performance
and the much better support for SVN, which is important for us as we can
slowly migrate from SVN->Git, while hgmercurial is still in the making
(and Python's SVN->Hg switch is for instance waiting for it).

Cheers,
  Anteru

Re: Deciding between Git/Mercurial

[Robin Rosenberg]

söndag 27 september 2009 14:24:32 skrev Anteru <newsgroups@catchall.shelter13.net>:
> Hi,
> 
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...

You have to read carefully. This (or the mercurial list) may not be the
most objective sources of information.

> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?

Besides msysgit there is JGit and a port of it to C# (and  thus any dotnet-ish 
language). The msysgit teams seems very committed and passionate about
the project, but they need more assistance from genuine Windows users. Note
that the current model of file locking can never work as well on Windows
as it does on Unix. Something better is needed for flawless operation.

> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...

Might be somewhat true, but msysgit works very well. Not sure how
mercurial handles unicode issues. CRLF issues seems to be ignored (not handled).

> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's

But those numbers cannot be communicated since they are local to your
clone.

> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?

git-cvsserver has to do something along those line  The numbering is
per file.

Maintainers tend to tag versions using the common numbered schem
and that is typically enough.

-- robin

Re: Deciding between Git/Mercurial

[Anteru]

Robin Rosenberg wrote:
> You have to read carefully. This (or the mercurial list) may not be the
> most objective sources of information.
Sure, but at the moment, I'm advocating pro-git, so I'm biased as well :)

> Might be somewhat true, but msysgit works very well. Not sure how
> mercurial handles unicode issues. CRLF issues seems to be ignored (not handled).
Yeah, well, the main question here is actually: Is improved support for
Windows one of the goals of future git development, or is this a
complete non-issue?

Cheers,
  Anteru

Re: Deciding between Git/Mercurial

[Alex Riesen]

On Sun, Sep 27, 2009 at 20:10, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Yeah, well, the main question here is actually: Is improved support for
> Windows one of the goals of future git development, or is this a
> complete non-issue?

I just hope it is not. Improved Windows support mostly
means lots of dead code (and that's the best outcome),
which no other platform can use.

Re: Deciding between Git/Mercurial

[Mark Struberg]

Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg?

LieGrue,
strub

--- On Sun, 9/27/09, Alex Riesen <raa.lkml@gmail.com> wrote:

> From: Alex Riesen <raa.lkml@gmail.com>
> Subject: Re: Deciding between Git/Mercurial
> To: newsgroups@catchall.shelter13.net
> Cc: git@vger.kernel.org
> Date: Sunday, September 27, 2009, 8:44 PM
> On Sun, Sep 27, 2009 at 20:10, Anteru
> <newsgroups@catchall.shelter13.net>
> wrote:
> > Yeah, well, the main question here is actually: Is
> improved support for
> > Windows one of the goals of future git development, or
> is this a
> > complete non-issue?
> 
> I just hope it is not. Improved Windows support mostly
> means lots of dead code (and that's the best outcome),
> which no other platform can use.
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


      

Re: Deciding between Git/Mercurial

[Anteru]

Mark Struberg schrieb:
> Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg?
The project is running on Windows/Linux (Windows being the primary
development platform, and we also expect most users to run Windows.)

For tooling, we use Trac at the moment (good integration with SVN), but
we're evaluating GitTrac, Trac/Mercurial and Redmine now (+ possible
migration paths.) For our build system, it's a non-issue anyway, as
git/mercurial have command line clients, and that's all we need.

Don't get me wrong with Git+msysgit on Windows, the point is simply if
we switch to git, can we expect that Windows will be supported for the
foreseeable future or is it possible that git may simply drop Windows
support completely? For Mercurial, this is a non-issue, as it is written
in Python, and Python will support both Windows and Linux.

As I said, I'm happy with using msysgit, but I cannot find any roadmap
etc. which helps me to determine how git and Windows is going to
continue (for instance, I can find some complaints that git's
performance is bad on Windows due to cygwin's fork()/exec(), is this
likely to get ever "fixed"? I guess git# will solve this as soon as it's
ready?)

Cheers,
  Anteru

Re: Deciding between Git/Mercurial

[Alex Riesen]

On Sun, Sep 27, 2009 at 21:18, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Don't get me wrong with Git+msysgit on Windows, the point is simply if
> we switch to git, can we expect that Windows will be supported for the
> foreseeable future or is it possible that git may simply drop Windows
> support completely? ...

Despite what I said, this is very unlikely (sadly). There are active developers
whose professional life happens in Windows. Besides, the project is open-
source and no one can stop you from taking over the maintainership of a port.

> As I said, I'm happy with using msysgit, but I cannot find any roadmap

There isn't any. Roadmaps are for projects with a guaranteed end of life :-p

> etc. which helps me to determine how git and Windows is going to
> continue (for instance, I can find some complaints that git's
> performance is bad on Windows due to cygwin's fork()/exec(), is this
> likely to get ever "fixed"?

Not likely. OTOH, msysGIT does not have that part of performance problem.

Re: Deciding between Git/Mercurial

[Erik Faye-Lund]

On Sun, Sep 27, 2009 at 9:18 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> Don't get me wrong with Git+msysgit on Windows, the point is simply if
> we switch to git, can we expect that Windows will be supported for the
> foreseeable future or is it possible that git may simply drop Windows
> support completely? For Mercurial, this is a non-issue, as it is written
> in Python, and Python will support both Windows and Linux.

The chance of Windows support being dropped from git is very unlikely
- there's way too many people depending on git for Windows already for
that to happen. Besides, git is open source, so you can always fix
Windows issues yourself.

As for Mercurial, Python programs aren't automatically portable to
Windows either. But I expect that they have the same very close to
zero chance of having Windows support dropped as git has.

> As I said, I'm happy with using msysgit, but I cannot find any roadmap
> etc. which helps me to determine how git and Windows is going to
> continue (for instance, I can find some complaints that git's
> performance is bad on Windows due to cygwin's fork()/exec(), is this
> likely to get ever "fixed"? I guess git# will solve this as soon as it's
> ready?)

Git (neither mainline nor msysgit) doesn't have any official roadmap
as far as I know. People just hack away on what they feel is
important. If you want to make sure something gets done, chip in the
development-time yourself.

As for the fork()-performance, this is only an issue for some tools
(if any at all - I don't think this issue exists in msysgit). In my
experience, git on Windows is faster than any other VCS I've ever used
on Windows.

-- 
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656

Re: Deciding between Git/Mercurial

[Pascal Obry]

Le 27/09/2009 20:10, Anteru a écrit :
> Yeah, well, the main question here is actually: Is improved support for
> Windows one of the goals of future git development, or is this a
> complete non-issue?

I think it is a non-issue as Git compile out of the box with Cygwin. 
Since many years I'm building Git almost daily from master under my 
Windows box using Cygwin. git-svn works like a charm too.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Deciding between Git/Mercurial

[Martin Langhoff]

On Sun, Sep 27, 2009 at 8:01 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> söndag 27 september 2009 14:24:32 skrev Anteru <newsgroups@catchall.shelter13.net>:
>> Mercurial's revision number system: With git, I get an SHA1 hash for
>> every commit, but it's not possible to see whether Hash1 is newer than
>> Hash2, while Mecurial also adds a running number to each commit. What's
>
> But those numbers cannot be communicated since they are local to your
> clone.

You can use git-describe, which will look for the latest tag, and make
a combo of latest tag, commits since the tag, short form of sha1. So
you get "v1.6.3-33-g1234" - 33 commits after 1.6.3. Works very well to
integrate in versioning. The git project itself uses it in the
Makefile to set the versions, same as the kernel folk do -- I use it
to version even RPM/DEBs.

hth,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Deciding between Git/Mercurial

[Felipe Contreras]

On Sun, Sep 27, 2009 at 3:24 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> Hi,
>
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...

IMO the key difference between hg and git is the storage model: hg
stores deltas, while git stores snapshots. That would mean that
certain operations are theoretically faster in git (e.g. checkout,
diff) while others faster in hg, although with git's packed format I
guess there's no operation faster in hg. This means that it doesn't
matter how much hg's python code improves, or if they even re-write
parts in C, they will never be able to match git's performance (unless
they change the storage model, which essentially means changing the
whole design -- won't happen).

All this is just guesses, I've thought about doing some measurements
but I haven't had time.

Cheers.

-- 
Felipe Contreras

Re: Deciding between Git/Mercurial

[Matthieu Moy]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> IMO the key difference between hg and git is the storage model: hg
> stores deltas, while git stores snapshots.

Mercurial stores regular snapshots, to make sure you never have to
apply too many deltas to get a snapshot. That's not so different from
what Git does with its packed format (the difference is that Git's
delta are not necessarily against the direct ancestor of the file).

AFAICT, both are snapshot-oriented, but both use a compression
algorithm based on delta.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Deciding between Git/Mercurial

[Johannes Schindelin]

Hi,

I tried to refrain from commenting in this thread, because I do not want 
to encourage people just to use msysGit and never even attempt to fix 
their own issues.

But I cannot let this go uncommented:

On Mon, 28 Sep 2009, Felipe Contreras wrote:

> IMO the key difference between hg and git is the storage model: hg 
> stores deltas, while git stores snapshots. That would mean that certain 
> operations are theoretically faster in git (e.g. checkout, diff) while 
> others faster in hg, although with git's packed format I guess there's 
> no operation faster in hg. This means that it doesn't matter how much 
> hg's python code improves, or if they even re-write parts in C, they 
> will never be able to match git's performance (unless they change the 
> storage model, which essentially means changing the whole design -- 
> won't happen).

That is wrong.  "git log -- <file>" will always be slightly faster in 
Mercurial, for all the reasons you mentioned.

In addition, Mercurial _has_ parts re-written in C for performance, which 
renders it not-exactly more portable if you ask me.  Last time I checked, 
there was no way to compile a Python module with MinGW (or for that 
matter, Python itself), but you needed MSVC...

Ciao,
Dscho

Re: Deciding between Git/Mercurial

[Felipe Contreras]

On Mon, Sep 28, 2009 at 1:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> I tried to refrain from commenting in this thread, because I do not want
> to encourage people just to use msysGit and never even attempt to fix
> their own issues.
>
> But I cannot let this go uncommented:
>
> On Mon, 28 Sep 2009, Felipe Contreras wrote:
>
>> IMO the key difference between hg and git is the storage model: hg
>> stores deltas, while git stores snapshots. That would mean that certain
>> operations are theoretically faster in git (e.g. checkout, diff) while
>> others faster in hg, although with git's packed format I guess there's
>> no operation faster in hg. This means that it doesn't matter how much
>> hg's python code improves, or if they even re-write parts in C, they
>> will never be able to match git's performance (unless they change the
>> storage model, which essentially means changing the whole design --
>> won't happen).
>
> That is wrong.  "git log -- <file>" will always be slightly faster in
> Mercurial, for all the reasons you mentioned.

Ok, thanks for pointing that out. I was thinking that maybe 'git
blame' would also be slightly faster on hg, but I really don't know.
Anyway, I think for most operations git would always be faster, and
more importantly; some essential operations will be faster (checkout,
diff <committish>).

-- 
Felipe Contreras

Re: Deciding between Git/Mercurial

[Bruce Stephens]

Felipe Contreras <felipe.contreras@gmail.com> writes:

[...]

> Ok, thanks for pointing that out. I was thinking that maybe 'git
> blame' would also be slightly faster on hg, but I really don't know.

hg (and git) store binary deltas.  AFAIK neither attempts to use those
to produce output for blame, diff, etc.  (git's deltas may well be
slightly different from mercurial's, in that git's can be deltas with
respect to something arbitrary so even if they had a suitable line-based
format they'd be useless for diff, blame.)

Similarly for the other major systems, with the exception of (I think)
bzr and darcs.  (I don't know how bzr or darcs actually work, but IIRC
they both have line-based storage that in principle might be usable in
computing blame and diff.)

[...]

Re: Deciding between Git/Mercurial

[Matthias Andree]

Johannes Schindelin schrieb:
> Hi,
> 
> I tried to refrain from commenting in this thread, because I do not want 
> to encourage people just to use msysGit and never even attempt to fix 
> their own issues.
> 
> But I cannot let this go uncommented:
> 
> On Mon, 28 Sep 2009, Felipe Contreras wrote:
> 
>> IMO the key difference between hg and git is the storage model: hg 
>> stores deltas, while git stores snapshots. That would mean that certain 
>> operations are theoretically faster in git (e.g. checkout, diff) while 
>> others faster in hg, although with git's packed format I guess there's 
>> no operation faster in hg. This means that it doesn't matter how much 
>> hg's python code improves, or if they even re-write parts in C, they 
>> will never be able to match git's performance (unless they change the 
>> storage model, which essentially means changing the whole design -- 
>> won't happen).
> 
> That is wrong.  "git log -- <file>" will always be slightly faster in 
> Mercurial, for all the reasons you mentioned.
> 
> In addition, Mercurial _has_ parts re-written in C for performance, which 
> renders it not-exactly more portable if you ask me.  Last time I checked, 
> there was no way to compile a Python module with MinGW (or for that 
> matter, Python itself), but you needed MSVC...

I have a shortish mercurial build script that works under Cygwin 1.5 and uses
msys, py2exe and iscc to build an installable Mercurial package, but I'm not
sure what this boils down to WRT C-versions of "modules". Maybe these are lumped
into the resulting hg.exe, I never bothered to check the details.

Re: Deciding between Git/Mercurial

[Dilip M]

You better evaluate yourself on the project you are going to use git
or Hg. Hg and git are used both by big companies. Google uses git to
host android, where as it also uses Hg to host google wave! So don't
go which company uses what, but try to evaluate... Check what is the
kind of operations your developers do often? Is it checkout, diff,
blame, also are they ready to do git gc often? What about developer
who is not interested in using cli? How do u care them for operations
they intended to do? what is the workflow? Which tools supports it to
great extent?

At the end of day, it is a developer who spends much time using tool..

Just  my opinion...... you put this question in Hg list, I bet you
will get the different views....

The above is solely my opinion and I am not biased! I think so:)



On 9/27/09, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Hi,
>
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
>
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
>
> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?
>
> Integration into tools: We're using Trac currently, which also has a
> nice binding to Mercurial (well, obviously easy to do as Mercurial is
> written in Python, just as Trac itself), while the git support is in
> development and looks quite alpha'ish. Do you plan to make it easier to
> integrate git with other tools by providing bindings to other languages,
> or is this a low-priority issue?
>
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).
>
> Cheers,
>   Anteru
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Sent from my mobile device

Dilip

Re: Deciding between Git/Mercurial

[Damien Wyart]

Hello,

* Anteru <newsgroups@catchall.shelter13.net> [2009-09-27 14:24]:
> Integration into tools: We're using Trac currently, which also has
> a nice binding to Mercurial (well, obviously easy to do as Mercurial
> is written in Python, just as Trac itself), while the git support is
> in development and looks quite alpha'ish. Do you plan to make it
> easier to integrate git with other tools by providing bindings to
> other languages, or is this a low-priority issue?

Trac is one of the the most well-known project management tools, but
Indefero is also interesting, and itegrates Git better than Trac:
http://www.indefero.net/


Best,

-- 
Damien Wyart

Re: Deciding between Git/Mercurial

[Steven Noonan]

On Mon, Sep 28, 2009 at 1:54 PM, Damien Wyart <damien.wyart@gmail.com> wrote:
> Hello,
>
> * Anteru <newsgroups@catchall.shelter13.net> [2009-09-27 14:24]:
>> Integration into tools: We're using Trac currently, which also has
>> a nice binding to Mercurial (well, obviously easy to do as Mercurial
>> is written in Python, just as Trac itself), while the git support is
>> in development and looks quite alpha'ish. Do you plan to make it
>> easier to integrate git with other tools by providing bindings to
>> other languages, or is this a low-priority issue?
>
> Trac is one of the the most well-known project management tools, but
> Indefero is also interesting, and itegrates Git better than Trac:
> http://www.indefero.net/
>

The interface looks very similar to Google Code's. I wonder, is this
the same thing that Google is using, or is it just mimicking the
interface?

- Steven

Re: Deciding between Git/Mercurial

[Sverre Rabbelier]

Heya,

On Mon, Sep 28, 2009 at 23:09, Steven Noonan <steven@uplinklabs.net> wrote:
> The interface looks very similar to Google Code's. I wonder, is this
> the same thing that Google is using, or is it just mimicking the
> interface?

Whow, it _does_ look a lot like Google Code, I doubt it's the same
code as I don't think Google Code's verison is open source, pretty
good copy either way.

-- 
Cheers,

Sverre Rabbelier

Re: Deciding between Git/Mercurial

[Randal L. Schwartz]

>>>>> "Sverre" == Sverre Rabbelier <srabbelier@gmail.com> writes:

Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same
Sverre> code as I don't think Google Code's verison is open source, pretty
Sverre> good copy either way.

I gotta get these guys on FLOSS Weekly.  Is anyone here a member of
the team?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Deciding between Git/Mercurial

[Sverre Rabbelier]

Heya,

On Tue, Sep 29, 2009 at 01:56, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> I gotta get these guys on FLOSS Weekly.  Is anyone here a member of
> the team?

There is of course the possiblity that the codesite team liked their
design so much that they based theirs off of the Indefero thing :P.

-- 
Cheers,

Sverre Rabbelier

Re: Deciding between Git/Mercurial

[Mike Ralphson]

2009/9/29 Randal L. Schwartz <merlyn@stonehenge.com>:
>>>>>> "Sverre" == Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same
> Sverre> code as I don't think Google Code's verison is open source, pretty
> Sverre> good copy either way.
>
> I gotta get these guys on FLOSS Weekly.  Is anyone here a member of
> the team?

Not a member of the team, just a user (and bug reporter!), but I
believe Indefero is almost all the work of one pretty amazing guy, Dr
Loïc d'Anterroches, cc'd above.

Mike

Re: Deciding between Git/Mercurial

[Matthieu Moy]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Heya,
>
> On Mon, Sep 28, 2009 at 23:09, Steven Noonan <steven@uplinklabs.net> wrote:
>> The interface looks very similar to Google Code's. I wonder, is this
>> the same thing that Google is using, or is it just mimicking the
>> interface?
>
> Whow, it _does_ look a lot like Google Code, I doubt it's the same
> code as I don't think Google Code's verison is open source, pretty
> good copy either way.

Indefero is a clone of Google code.

  http://www.google.com/search?q=indefero+clone+google+code

(most links are in French, but this is what they say)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Deciding between Git/Mercurial

[Sverre Rabbelier]

Heya,

On Tue, Sep 29, 2009 at 10:21, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>  http://www.google.com/search?q=indefero+clone+google+code
>
> (most links are in French, but this is what they say)

Might I suggest for those that are no masters of the french language:

http://translate.google.com/translate_s?hl=en&clss=&q=indefero+clone+google+code&sl=en&tl=fr


-- 
Cheers,

Sverre Rabbelier

Re: Deciding between Git/Mercurial

[Jakub Narebski]

Anteru <newsgroups@catchall.shelter13.net> writes:

> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
> 
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...

On one hand side Git relies quite a bit on POSIX features; also some
of git commands are implemented as shell scripts, or are written in
Perl.  Nevertheless even if people stopped working on msysGit
("native" Windows port), which I don't see happening, there is always
and will be git from Cygwin.  But the msysGit team is active, and I
predict that it soon would be full equivalent of Git on Linux (there
are some corner cases yet).  Lately there was even some work on
support infrastructore for having Git be developed in MSVC.

On the other hand side Mercurial does have some parts of its code
rewritten in C for efficiency.  I do wonder how portable it is, and
what is more important how portable is the interface between C and
Python.

But I do not use MS Windows for development, and I do not use
Mercurial...

> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?

First, you have to remember that this 'number of commit' thingy is
*local* to your repository, so you cannot use commit numbers to
communicate with other developers.  This is inherent and unavoidable
property of 'revision numbering': commit identifiers must be derivable
from commit contents (e.g. SHA-1 used by Git), or must be local to
clone of repository (e.g. Mercurial), or there must be some central
numbering authority (like in centralized SCMs like Subversion).

Second, I think advantages of revision numbering (running number) are
overemphasized.  I don't see how numbers such as 12678 and 12687 are
easier to use than even abbreviated SHA-1 IDs like f06e7eb, never mind
the "<branch>~<n>" syntax Git uses to refer to n-th ancestor of
current tip of given branch.  Besides with nonlinear history with
revision numbers such as 12678 and 12687 you know that 12678 is older
than 12687 if and only if 12678 and 12687 are on the same line of
development.

Third, I think it would be possible to emulate mercurial behaviour
with using lightweight 'number' tags for numbering, created from a
hook.

> Integration into tools: We're using Trac currently, which also has a
> nice binding to Mercurial (well, obviously easy to do as Mercurial is
> written in Python, just as Trac itself), while the git support is in
> development and looks quite alpha'ish. Do you plan to make it easier to
> integrate git with other tools by providing bindings to other languages,
> or is this a low-priority issue?

Well, I think that the problem with implementing bindings to other
programming languages is that there is currently no such thing like
the Git library (well, there are beginnings of one).  This is caused
by the fact that originally git commands were written in run-once
philosophy, and e.g. rely on operating system to do the cleanups.

So far bindings to other languages either call Git commands (like
Git.pm Perl interface from Git, or JavaGit), or are native Git
(re)implementations relying not on stable API, but on stable
repository format (JGit for Java, Dulwich for Python, partially Grit
for Ruby).  

The emphasisis in Git was (and is) for it to be *scriptable*, rather
than extensible through plugins.


BTW. the fact that JGit is reimplementation allows it to be use
different license than Git itself; license which makes JGit and EGit
to be license-compatibile with Eclipse, and allow to distribute EGit
as full Eclipse project.

> 
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).

hgmercurial? or hgsubversion?

There is also fact that git has superior support for multi-branch
development, which I think is the workflow most suited for distributed
development.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Deciding between Git/Mercurial

[Jakub Narebski]

Jakub Narebski <jnareb@gmail.com> writes:

> Anteru <newsgroups@catchall.shelter13.net> writes:
> 
> > I'm currently evaluating DVCS for a project, and we're at a point where
> > it comes down to either Mercurial or Git. Right now, I'm advocating for
> > Git, while my co-workers like Mercurial, so I'd like to provide some
> > good arguments in favor of git. Unfortunately, I'm not a git expert, so
> > I hope I can get some help here ...
[...]

> > So far, my key arguments are that git is more robust (more projects
> > using it, larger developer base), of course git's excellent performance
> > and the much better support for SVN, which is important for us as we can
> > slowly migrate from SVN->Git, while hgmercurial is still in the making
> > (and Python's SVN->Hg switch is for instance waiting for it).
> 
> hgmercurial? or hgsubversion?
> 
> There is also fact that git has superior support for multi-branch
> development, which I think is the workflow most suited for distributed
> development.

See also http://whygitisbetterthanx.com/#hg

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Deciding between Git/Mercurial

[Anteru]

> First, you have to remember that this 'number of commit' thingy is
> *local* to your repository, so you cannot use commit numbers to
> communicate with other developers.  This is inherent and unavoidable
Ah cool, thanks for clarifying this.

>> So far, my key arguments are that git is more robust (more projects
>> using it, larger developer base), of course git's excellent performance
>> and the much better support for SVN, which is important for us as we can
>> slowly migrate from SVN->Git, while hgmercurial is still in the making
>> (and Python's SVN->Hg switch is for instance waiting for it).
> 
> hgmercurial? or hgsubversion?
hgsubversion of course, which is supposed to be what git-svn is already.
At the moment, I already use git with our SVN server, so I can show some
of the advantages (for instance, renaming works much better than with
SVN itself :) ), and I guess it also makes the migration easier as
everyone can try with Git locally and we switch from SVN to Git once
everyone has switched locally.

Thanks for all the input so far!

Cheers,
  Anteru

Re: Deciding between Git/Mercurial

[Leo Razoumov]

On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> [..snip..]
>  Besides with nonlinear history with
>  revision numbers such as 12678 and 12687 you know that 12678 is older
>  than 12687 if and only if 12678 and 12687 are on the same line of
>  development.
>

The statement above is incorrect!! In a Mercurial repo local revision
numbers are strictly ordered in commit time. 12678 < 12687 means that
12678 was committed prior to 12687. But these two commits could belong
to two completely unrelated lines of development.

--Leo--

Re: Deciding between Git/Mercurial

[Jakub Narebski]

On Tue, 29 Sep 2009, Leo Razoumov wrote:
> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > [..snip..]
> >  Besides with nonlinear history with
> >  revision numbers such as 12678 and 12687 you know that 12678 is older
> >  than 12687 if and only if 12678 and 12687 are on the same line of
> >  development.
> 
> The statement above is incorrect!! In a Mercurial repo local revision
> numbers are strictly ordered in commit time. 12678 < 12687 means that
> 12678 was committed prior to 12687. But these two commits could belong
> to two completely unrelated lines of development.

This is impossible with distributed development.  If the second branch
comes from other repository, with commits _created_ (in that repository)
earlier than commits in current repository, but commits in first
branch (from current repository) were created earlier than _fetching_
those commits in second branch:

  .---.---.---.---x---1---2---3---M---.    
                   \             /
                    \-A---B---C-/             <-- from repository B


Either you would have to change commits numbers, and therefore they would
be not stable, or you would have to change commit time to mean 'time this
commit got into current repository', which would kill performance for sure.

-- 
Jakub Narebski
Poland

Re: Deciding between Git/Mercurial

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [..snip..]
>> >  Besides with nonlinear history with
>> >  revision numbers such as 12678 and 12687 you know that 12678 is older
>> >  than 12687 if and only if 12678 and 12687 are on the same line of
>> >  development.
>> 
>> The statement above is incorrect!! In a Mercurial repo local revision
>> numbers are strictly ordered in commit time. 12678 < 12687 means that
>> 12678 was committed prior to 12687. But these two commits could belong
>> to two completely unrelated lines of development.
>
> This is impossible with distributed development.

Yes, the accurate statement is (I think): "In a Mercurial repo local
revision numbers are strictly ordered according _the time when the_
_commit entered the repository_" (i.e. the time you did a merge, not
the time the other guy did the commit).

Just tested:

$ hg log
changeset:   3:4d6db21df0cd
tag:         tip
parent:      1:31f8406ae59c
parent:      2:33bfb84a5113
user:        Matthieu Moy <Matthieu.Moy@imag.fr>
date:        Tue Sep 29 21:54:25 2009 +0200
summary:     merge

changeset:   2:33bfb84a5113
parent:      0:a508b050e5ae
user:        Matthieu Moy <Matthieu.Moy@imag.fr>
date:        Tue Sep 29 21:54:02 2009 +0200
summary:     in branch bar

changeset:   1:31f8406ae59c
user:        Matthieu Moy <Matthieu.Moy@imag.fr>
date:        Tue Sep 29 21:54:11 2009 +0200
summary:     in branch foo

changeset:   0:a508b050e5ae
user:        Matthieu Moy <Matthieu.Moy@imag.fr>
date:        Tue Sep 29 21:53:33 2009 +0200
summary:     init

Either I have a time machine at home, or changesets 1 was not made
before changeset 2.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Deciding between Git/Mercurial

[Leo Razoumov]

On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>  > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
>  > > [..snip..]
>  > >  Besides with nonlinear history with
>  > >  revision numbers such as 12678 and 12687 you know that 12678 is older
>  > >  than 12687 if and only if 12678 and 12687 are on the same line of
>  > >  development.
>  >
>  > The statement above is incorrect!! In a Mercurial repo local revision
>  > numbers are strictly ordered in commit time. 12678 < 12687 means that
>  > 12678 was committed prior to 12687. But these two commits could belong
>  > to two completely unrelated lines of development.
>
>
> This is impossible with distributed development.  If the second branch
>  comes from other repository, with commits _created_ (in that repository)
>  earlier than commits in current repository, but commits in first
>  branch (from current repository) were created earlier than _fetching_
>  those commits in second branch:
>
>   .---.---.---.---x---1---2---3---M---.
>                    \             /
>                     \-A---B---C-/             <-- from repository B
>
>
>  Either you would have to change commits numbers, and therefore they would
>  be not stable, or you would have to change commit time to mean 'time this
>  commit got into current repository', which would kill performance for sure.
>

Jakub,
in Mercurial sequential commit numbers are local to a repo and are not
unique between the clones. Unique ID is SHA1 as in git. So mercurial
commit 127:aaf123453dfgdfgddd...
means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
In another clone commit 127 might mean completely different thing.
Sequential commit numbers are strictly for "local convenience".

--Leo--

Re: Deciding between Git/Mercurial

[Björn Steinbrink]

On 2009.09.29 20:49:52 -0400, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Tue, 29 Sep 2009, Leo Razoumov wrote:
> >  > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> >  > > [..snip..]
> >  > >  Besides with nonlinear history with
> >  > >  revision numbers such as 12678 and 12687 you know that 12678 is older
> >  > >  than 12687 if and only if 12678 and 12687 are on the same line of
> >  > >  development.
> >  >
> >  > The statement above is incorrect!! In a Mercurial repo local revision
> >  > numbers are strictly ordered in commit time. 12678 < 12687 means that
> >  > 12678 was committed prior to 12687. But these two commits could belong
> >  > to two completely unrelated lines of development.
> >
> > This is impossible with distributed development.  If the second branch
> >  comes from other repository, with commits _created_ (in that repository)
> >  earlier than commits in current repository, but commits in first
> >  branch (from current repository) were created earlier than _fetching_
> >  those commits in second branch:
> >
> >   .---.---.---.---x---1---2---3---M---.
> >                    \             /
> >                     \-A---B---C-/             <-- from repository B
> >
> >
> >  Either you would have to change commits numbers, and therefore they would
> >  be not stable, or you would have to change commit time to mean 'time this
> >  commit got into current repository', which would kill performance for sure.
> >
> 
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".

To quote his first mail:
	First, you have to remember that this 'number of commit' thingy
	is *local* to your repository, so you cannot use commit numbers
	to communicate with other developers.

With the above example, he has just shown that even with those local
commit numbers, you can't tell that commit X is older than commit Y just
because X < Y.

Björn

Re: Deciding between Git/Mercurial

[Andreas Ericsson]

On 09/30/2009 02:49 AM, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski<jnareb@gmail.com>  wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>>   >  On 2009-09-28, Jakub Narebski<jnareb@gmail.com>  wrote:
>>   >  >  [..snip..]
>>   >  >   Besides with nonlinear history with
>>   >  >   revision numbers such as 12678 and 12687 you know that 12678 is older
>>   >  >   than 12687 if and only if 12678 and 12687 are on the same line of
>>   >  >   development.
>>   >
>>   >  The statement above is incorrect!! In a Mercurial repo local revision
>>   >  numbers are strictly ordered in commit time. 12678<  12687 means that
>>   >  12678 was committed prior to 12687. But these two commits could belong
>>   >  to two completely unrelated lines of development.
>>
>>
>> This is impossible with distributed development.  If the second branch
>>   comes from other repository, with commits _created_ (in that repository)
>>   earlier than commits in current repository, but commits in first
>>   branch (from current repository) were created earlier than _fetching_
>>   those commits in second branch:
>>
>>    .---.---.---.---x---1---2---3---M---.
>>                     \             /
>>                      \-A---B---C-/<-- from repository B
>>
>>
>>   Either you would have to change commits numbers, and therefore they would
>>   be not stable, or you would have to change commit time to mean 'time this
>>   commit got into current repository', which would kill performance for sure.
>>
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
>

Personally I much prefer the "commit'ish-backward" notation of git,
where HEAD~4 means "the commit 4 commits back from HEAD".

You'd get awfully tired of writing the six-digit "shorthand" numbers
of large projects fairly quickly, I imagine.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Deciding between Git/Mercurial

[Jakub Narebski]

On Wed, 30 Sep 2009, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>>> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:

>>>> [..snip..]
>>>>  Besides with nonlinear history with
>>>>  revision numbers such as 12678 and 12687 you know that 12678 is older
>>>>  than 12687 if and only if 12678 and 12687 are on the same line of
>>>>  development.
>>>
>>> The statement above is incorrect!! In a Mercurial repo local revision
>>> numbers are strictly ordered in commit time. 12678 < 12687 means that
>>> 12678 was committed prior to 12687. But these two commits could belong
>>> to two completely unrelated lines of development.
>>
>> This is impossible with distributed development.  If the second branch
>>  comes from other repository, with commits _created_ (in that repository)
>>  earlier than commits in current repository, but commits in first
>>  branch (from current repository) were created earlier than _fetching_
>>  those commits in second branch:
>>
>>   .---.---.---.---x---1---2---3---M---.
>>                    \             /
>>                     \-A---B---C-/             <-- from repository B
>>
>>
>>  Either you would have to change commits numbers, and therefore they would
>>  be not stable, or you would have to change commit time to mean 'time this
>>  commit got into current repository', which would kill performance for sure.
> 
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".

Yes, I know that in Mercurial commit numbers are local to repository,
and even written about it (that sequential commit numbers are possible
only either as local identifiers, or in centralized workflow).

The issue I was writing about that sequential commit numbers cannot
tell us if commit was earlier or later than some other commit based
solely on those commit numbers.  As other people in this thread wrote
Mercurial numbers commits not in order of commit creation, but in
order of commit arriving (being present) in given repository.  So
commit numbers are not 'strictly ordered in commit time', but ordered
in 'time commit got into current (local) repository'.


I'd like also to note that this means that at some time Mercurial has
to number all those commit it got on fetch / pull from remote repository.
This can be a lot of work... work which Git doesn't have to do (OTOH Git
creates index for packfile on local side after fetch...).

-- 
Jakub Narebski
Poland

Re: Deciding between Git/Mercurial

[Paolo Bonzini]

On 09/27/2009 02:24 PM, Anteru wrote:
> What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?

While not exactly the same thing, 'git describe' is very helpful in 
comparing versions (if you know that one is an ancestor of the other).

Paolo

Re: Deciding between Git/Mercurial

[Daniele Segato]

On Sun, Sep 27, 2009 at 2:24 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
>
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...


Can I propose to make this discussion cross-mailing list adding the hg
mailing list to the CC?
I think it would be a good discussion if we don't end up flaming.
Let me know what you think about it


about the Windows+Git compatibility, you may consider TortoiseGit too
for the not-CLI-oriented guys; I've seen it a while ago and it seems
pettry well integrated with windows


> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?


If you tag a commit then you should be able to see how many commits
there are from that one issuing a git describe
(found on the internet)
git commit -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0


> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).

Re: Deciding between Git/Mercurial

[Dilip M]

On Tue, Sep 29, 2009 at 2:14 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> Can I propose to make this discussion cross-mailing list adding the hg
> mailing list to the CC?  I think it would be a good discussion if we don't
> end up flaming.  Let me know what you think about it

We will probably end in flames. Its same as comparing Vim and Emacs, Python
and Perl...

...this comparison is all ver web. Checkout!

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

My *personnel*  opinion is, If it is for project _only_ on UNIX, than GIT and
repo tool from Google will be killing combination.

If project is on both Windows & UNIX (But consider where do you compile your
code), than hg doesn't have matching!



-- 
Dilip

Re: Deciding between Git/Mercurial

[Matthias Andree]

Anteru schrieb:

> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...

That tale is told all over, but that doesn't make it truer. I've never had
issues getting a Cygwin version of git to work properly (haven't tried the
msysgit or jgit variants, never felt the need), and integration went smooth.

With Mercurial, getting it integrated with a Windows-native Emacs (Cygwin emacs
doesn't work for me but hangs on startup) was somewhat of an undertaking even
with Cygwin's bash (rather than cmdproxy) underneath Emacs. It boiled down to
building Mercurial with py2exe and create an installer and use the compiled
hg.exe which I find starts rather slowly.

> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).

Yes, but beware of git-svn under Cygwin 1.5 - that works for svn+ssh:// URLs,
but https:// or file:// don't work well because the underdocumented gazillion of
dependencies piece of sh.. called apr does stupid things WRT temporary files
since the Cygwin Subversion 1.6 days. Cygwin's Subversion 1.5 fared better.

I'm not sure about msysgit or jgit projects, but for Cygwin you'll definitely
want to take the plunge and go for Cygwin 1.7 which is still in Beta (because
that allows you to remove a file and create a file with the same name, which
doesn't work with Cygwin 1.5).

Re: Deciding between Git/Mercurial

[Daniel Barkalow]

On Wed, 30 Sep 2009, Matthias Andree wrote:

> Anteru schrieb:
> 
> > First of all, what's the matter with git and Windows, is there some
> > long-term commitment to make git work on Windows as well as on Linux?
> > I'm using msysgit on Windows, and personally I'm happy with it, but my
> > co-workers constantly nag that Mercurial has superior portability ...
> 
> That tale is told all over, but that doesn't make it truer. I've never had
> issues getting a Cygwin version of git to work properly (haven't tried the
> msysgit or jgit variants, never felt the need), and integration went smooth.

Git works fine under Windows for people who use Cygwin. Portability to 
Windows is more about working for users who don't use a shell of any sort 
or the "Run..." dialog. I don't know how Mercurial does on that metric, 
anyway, but it's a lot more meaningful that the question of whether the 
software works in your POSIX environment when the underlying kernel is not 
very suitable.

	-Daniel
*This .sig left intentionally blank*

Re: Deciding between Git/Mercurial

[Dilip M]

Hi Anteru,

On Sun, Sep 27, 2009 at 5:54 PM, Anteru  wrote:

..snip..

> So far, my key arguments are that git is more robust (more projects using
> it, larger developer base), of course git's excellent performance and the
> much better support for SVN, which is important for us as we can slowly
> migrate from SVN->Git, while hgmercurial is still in the making (and
> Python's SVN->Hg switch is for instance waiting for it).

So finally which you choosed? Just curious?



-- 
Dilip

Re: Deciding between Git/Mercurial

[Anteru]

Dilip M schrieb:
> Hi Anteru,
> 
> On Sun, Sep 27, 2009 at 5:54 PM, Anteru  wrote:
> 
> ..snip..
> 
>> So far, my key arguments are that git is more robust (more projects using
>> it, larger developer base), of course git's excellent performance and the
>> much better support for SVN, which is important for us as we can slowly
>> migrate from SVN->Git, while hgmercurial is still in the making (and
>> Python's SVN->Hg switch is for instance waiting for it).
> 
> So finally which you choosed? Just curious?

Bzr, it has even better SVN interop, works the same across all
platforms, performance-wise, Bzr 2.x turned out to be more than
sufficient and the UI tools are quite polished.

Thanks for all the comments on Git and Hg!

Cheers,
  Anteru

Re: Deciding between Git/Mercurial

[Dilip M]

On Thu, Oct 22, 2009 at 12:20 PM, Anteru <Anteru@shelter13.net> wrote:

> Bzr, it has even better SVN interop, works the same across all
> platforms, performance-wise, Bzr 2.x turned out to be more than
> sufficient and the UI tools are quite polished.
>
> Thanks for all the comments on Git and Hg!

Surprised to know. I was expecting hg or GIT :)

Do you mind to share the checks done / piloting done while choosing
Bzr over GIT or HG

I bet, it is useful for many ppl in this list too.



-- 
Dilip

Re: Deciding between Git/Mercurial

[Anteru]

Dilip M schrieb:
> Surprised to know. I was expecting hg or GIT :)
Yeah, me too, actually, Bzr was no contender at first.

> Do you mind to share the checks done / piloting done while choosing
> Bzr over GIT or HG
> 
> I bet, it is useful for many ppl in this list too.

I'm going to blog about this, in the hope that it will help more people
who want to switch away from SVN. I'm not so sure whether sending it
here will help, because in order to be fair, I would have to send the
same to the Bzr and Hg mailing lists, and this is a sure recipe for a
flame-war :)

Cheers,
  Anteru