Recent Features
| |||||||||||||
Hg Init: a Mercurial tutorialHg Init: a Mercurial tutorialPosted Feb 24, 2010 22:45 UTC (Wed) by nix (subscriber, #2304)In reply to: Hg Init: a Mercurial tutorial by bjacob Parent article: Hg Init: a Mercurial tutorial
1) it's pretty easy to reverse such 'damage' (rewind the affected branches
and prune).
2) git has been a native application on Windows for years now.
(Log in to post comments)
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 0:59 UTC (Thu) by bjacob (subscriber, #58566) [Link]
"2) git has been a native application on Windows for years now."
Then the wikipedia must be wrong:
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 1:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
it looks like wikipedia has been fixed now.
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 4:02 UTC (Thu) by dkrawchuk (subscriber, #21896) [Link]
I use git daily in Windows to manage Unigraphics part files which are large binary files and it works well and is easy enough to use. A half a dozen commands to learn and you are away. http://www.kernel.org/pub/software/scm/git/docs/everyday.... is enough to get the average person going. I tried hg but it does not handle binary files well.
Hg Init: a Mercurial tutorial Posted Feb 25, 2010 8:55 UTC (Thu) by bboissin (subscriber, #29506) [Link]
In what way does it not handle binary files well, in theory there aren't
many differences in the way they deal with them.
Hg Init: a Mercurial tutorial Posted Feb 26, 2010 0:46 UTC (Fri) by cortana (subscriber, #24596) [Link]
It handles binary files just fine. It handles *large* files (text or binary) poorly though. Specifically I am referring to the Windows port (msysgit) which tries to compress files before sending them to the server; if it runs out of memory (which it will, since it's only a 32-bit application and so can only address a couple of GiB of RAM) then it dies with a typically obtuse error message.
Hg Init: a Mercurial tutorial Posted Feb 26, 2010 6:43 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
git also has issues with large files.
the point at which a file gets large enough to cause problems (and what the problems are) are obviously different between the two.
Hg Init: a Mercurial tutorial Posted Feb 26, 2010 9:43 UTC (Fri) by cortana (subscriber, #24596) [Link]
Whoops! To clarify, I was referring to Git rather than "it" (hg) :)
Hg Init: a Mercurial tutorial Posted Mar 4, 2010 10:42 UTC (Thu) by jmansion (guest, #36515) [Link]
> 2) git has been a native application on Windows for years now.
There's a difference between 'runs on Windows' and 'is usable on Windows'.
Does it have support for understanding that its more convenient for text files on Windows to have CRLF endings, and that it should hide this when editing cross-platform files on Windows and posix platforms?
hg seems nice to me. I was enjoying bzr too but hgEclipse is sufficiently better than bzrEclipse that I'm transitioning to hg.
To be honest, having upstream devs who care about the cross-platform stuff is enough to make hg a clear win for me compared to having a secondary port for Windows. It doesn't really matter to me if git is better than hg on linux.
Hg Init: a Mercurial tutorial Posted Mar 4, 2010 15:20 UTC (Thu) by nye (guest, #51576) [Link]
>Does it have support for understanding that its more convenient for text files on Windows to have CRLF endings, and that it should hide this when editing cross-platform files on Windows and posix platforms?
Yes.
Git has the expected heuristics to decide whether a file is binary or text, along with the ability to add a hint if you need to.
It's also capable of detecting a mixture of line endings and can be configured to convert them all one way or the other if you want it to (see the safecrlf option).
(Although I have to say that it's been *years* since I came across a single Windows application that choked on LF-only line endings, and whose name isn't 'notepad.exe'.)
>To be honest, having upstream devs who care about the cross-platform stuff
Git seems to have more attention paid to the CRLF problem than the other VCSes I've used in the past, though I've never used Mercurial. Not to mention that portability is a big deal for Git which goes to great lengths to work on a wide variety of platforms.
|
|||||||||||||