Bruno Medeiros wrote:
> Hum, my impression is that Git is actually pretty mindful about data integrity, not just on history, but on commits as well. However, it also seems like Git was designed with Linux in mind, so Git on Windows is kinda like a second-class platform (for example, performance is apparently lower on Windows). But hopefully that will improve on the future.
> 
	Performance was actually horrendous on windows last year, not just
"lower".

> The comments above made tip my preference slightly over to Mercurial. But I think ultimately the decision of whether I would use Mercurial or Git would be decided more by external factors, like the quality of IDE-integrated tools (read: Eclipse plugins), and the availability or preference of those DVCS in hosting-sites/organizations. For example Google Code only supports Mercurial. On the other hand the Eclipse Foundation is moving their repositories to Git. (if it wasn't for that I'd likely have gone with Mercurial and not looked back on Git)
> 
	I don't know how good it is, but I believe there is an Eclipse
plugin for Mercurial.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 11/18/10 8:20 PM, "Jérôme M. Berger" wrote:
> 	Performance was actually horrendous on windows last year, not just
> "lower".

That's what you say.

I say that I've been happily using Git on Windows for over two years without noticing any performance problems.

Now what?

On 11/18/10 8:18 PM, "Jérôme M. Berger" wrote:
> 	It deserves the label "data corruption" since Git did the
> conversion when committing the file, which means that the version
> stored in the history was corrupted.

Okay, so you I guess you were pretty unlucky since after you turned the feature on, Git promptly misdetected one of your files, and you didn't notice that when you committed your changes – if you had looked at the diff for whatever reason, you would have probably noticed that something is wrong (I have this habit of briefly looking what I am checking in, but that's probably from my SVN-based OSS work).

I don't really know if there is anything that can be done about this though – in fact Git developers are asked to turn the feature on by default for usability reasons quite regularly, if I remember correctly. What certainly could be done is improving the auto detection algorithms, but that would be an issue for the Git ML/bug tracker.

In any case, you might be interested in the fact that Mercurial seems to have real issues with data corruption on Windows, see for example the following reports:

http://serverfault.com/questions/91681/mercurial-repository-corruption
http://stackoverflow.com/questions/2563178/corrupt-mercurial-repository-cannot-update

klickverbot wrote:
> On 11/18/10 8:18 PM, "Jérôme M. Berger" wrote:
>>     It deserves the label "data corruption" since Git did the
>> conversion when committing the file, which means that the version
>> stored in the history was corrupted.
> 
> Okay, so you I guess you were pretty unlucky since after you turned the feature on, Git promptly misdetected one of your files, and you didn't notice that when you committed your changes – if you had looked at the diff for whatever reason, you would have probably noticed that something is wrong (I have this habit of briefly looking what I am checking in, but that's probably from my SVN-based OSS work).
> 
	One of the point here is that I didn't "turn the feature on". It
was turned on by default. Moreover, the first time it happened, I
was importing data from SVN so I didn't look at all the diffs (the
next time it happened, I was adding a new file, so I didn't go
through the whole diff and didn't notice the difference).

> In any case, you might be interested in the fact that Mercurial seems to have real issues with data corruption on Windows, see for example the following reports:
> 
> http://serverfault.com/questions/91681/mercurial-repository-corruption http://stackoverflow.com/questions/2563178/corrupt-mercurial-repository-cannot-update
> 
	Well, at least the second one looks like the user removed some
files from the .hg repository (by recursively removing all files
whose name fit a certain pattern). This kind of mistake would affect
Git too (or any system where the repository is located alongside the
sources).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

klickverbot wrote:
> On 11/18/10 8:20 PM, "Jérôme M. Berger" wrote:
>>     Performance was actually horrendous on windows last year, not just
>> "lower".
> 
> That's what you say.
> 
> I say that I've been happily using Git on Windows for over two years without noticing any performance problems.
> 
> Now what?

	Well, I went back to the message I posted at the time (on June 6
2009 in digitalmars.D) and I need to amend that: "git clone"
performance is horrendous (more than 4 times slower than Mercurial).
Other commands are generally slightly slower than Mercurial but
acceptable, except import from SVN which took several hours for Git
and 5min for Mercurial (but that is not too important since you
don't import from SVN every day, clone performance is a lot more
problematic IMO).

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Jérôme M. Berger wrote:
> 	Well, I went back to the message I posted at the time (on June 6
> 2009 in digitalmars.D)

	Sorry, that should read on June *3*. The thread subject was "Re:
Source control for all dmd source (Git propaganda =)" if you want to
look it up.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr