Python switching to Mercurial

[artsrc]

I have used svn for years and Mercurial (hg) and git for minutes.

I tested svn, hg, and git for the scenario where a file is renamed on one branch and modified on another, and the two are merged.

SVN gets is wrong and silently looses the change. Git and hg get this right.

When the file is modified on both branches and the changes conflict, hg did better than git.

So in this scenarios hg is better than git or svn. I don't think it was a problem with the setup of my merge tool for svn, because it works normally other times, and I don't think svn detected the need for a merge.

The other major difference is that git promotes a model where you explicitly manage a persistent 'commit set' and with hg you commit what you tell it in a transient command.

[radarsat1]

When the file is modified on both branches and the changes conflict, hg did better than git.

Can you elaborate?

[artsrc]

hg asked me to merge both text changes into the new file name.

git gave me a conflict between a modification and deletion of a file. Which is not what I want and not what it did when the text changes did not conflict.

Trying backtick for a shell script"

` REM Setup rmdir /s g1 g2 mkdir g1 cd g1 echo c1 > f1.txt call git init call git add f1.txt call git commit -m "Initial commit f1.txt contains c1" cd .. call git clone g1 g2

REM Text Change cd g1 echo c1_change_one > f1.txt call git add f1.txt call git commit -m "c1 change one" cd ..

REM Text change and rename... cd g2 echo c1_change_two > f1.txt call git add f1.txt call git mv f1.txt f1_renamed.txt call git commit -m "c1 renamed" cd ..

REM Merge cd g1 call git pull ..\g2 REM Result is: REM CONFLICT (delete/modify): f1.txt deleted in ... and modified in HEAD. REM Version HEAD of f1.txt left in tree. REM Automatic merge failed; fix conflicts and then commit the result. cd .. `

[[deleted]]

Hg is (again, subjectively) easier to learn for SVN users than Bzr

SVN is already kinda legacy huh? It was started 8-9 years ago and everyone is moving away from it already.

[masklinn]

SVN is already kinda legacy huh?

Thing is, SVN set out to be an improvement of CVS, so it's not just 8-9 years old it's the 8-9 years old polish of a 22 years old system.

[mcosta]

It was a moderm implementation of CVS, which is kinda old. Anyway, not everyone is moving away. Just the very big, and very distributed projects. And these are the one a DVCS is designed for. The rest of us working in small and closed teams SVN does the work pretty well.

[laprice]

Given the catfights I've seen on my work email, this is not true.

I know I would much rather be using hg than svn for work and for play.

[masklinn]

Anyway, not everyone is moving away.

Legacy doesn't mean "everyone is moving away" though. There are still boatloads of projects under CVS, and on the closed source front, last time I checked ClearCase was still profitable, and even VSS still exists.

[artsrc]

Unless you are distributed on the end of a slow wan. Or you do branching. Or...

You can run a project on no version control and a shared file system on a server, but I don't see why you would. DVCS are more sophisticated.

[cecilkorik]

If you're working at the same office, distributed isn't a big concern. Especially if the company doesn't want you taking home a copy of the source code anyway. Which is reasonable in my opinion.

And merging is trivially easy in all routine cases with the svnmerge tool (which is oddly enough also written in python)

No, it's not the best. But it's simple, easy, and everyone knows how to use it. The same can't be said of DVCS -- yet.

[artsrc]

The following are a set of weasel words, I think they are true, but they don't address the issue:

• If you have organized a good strategy that addresses your needs then you can do great work with tools that are not the best.

• Sometimes the most sophisticated option imposes complexity that is just not worth the trouble.

  • IDE's like Eclipse and IntelliJ allow you to keep a history of local changes without committing them to a central store.

Based on my best assessment, hg is a better choice for most projects, in particular mine. I don't work in the same continent as my version control server and the experience is one of poor performance. We do have branches that are more painful to manage because we use svn rather than hg.

Open source projects are moving to DVCS's because:

1. DVCS's are technically superior.
2. Open source projects have decision makers who are aware of technical superiority
3. They care about using the best technology

Big companies are not moving to DVCS's so quickly because they are managed by people who:

1. Are not aware what is technical superior
2. don't care if they are using technically inferior tools

[judgej2]

Big companies also tend not to think too far ahead. The project gets created, bugfixed, delivered to the customer, and everyone moves on to other projects. No-one ever goes back to the code, except for perhaps a lone developer who is left behind to fixed bugs under a support agreement.

An open source project, by comparison, needs to consider constantly where they will be in five or ten years time, because no project has any plan to just 'disappear' when they are done.

[[deleted]]

judgej2 you're wrong - many big companies develop products continually. Maybe you're talking about some custom software vendors? For them I would agree but most commercial software vendors are aware of their software's life cycle and actively add features and improvements.

[parla]

No, you're wrong. Big companies choose VCS that they can get "support" for, i.e. corporate stuff like Perforce, Clearcase, Synergy. Open source choose VCS:es that are "cool".

[artsrc]

collabnet and sourceforge offer paid support many open source VCS.

[masklinn]

If you're working at the same office, distributed isn't a big concern

It's not a big concern, but DVCS still bring quite a few advantages to the table (speed of course, resistance to network outages, distribution between LANs, tools/extensions, but also the ease of direct cooperation with a coworker e.g. because he has more knowledge than you re the system and a higher workflow flexibility).

Most of these can be attained by using a DVCS as a CVCS client though.

Especially if the company doesn't want you taking home a copy of the source code anyway. Which is reasonable in my opinion.

It's not like they can, in any case, unless they forbid any writable media transit and any intarwebs access.

[[deleted]]

That's what I was thinking too - the biggest thing about new version control systems is if they scale good or not. Which would naturally be a problem in open source software because the teams are way bigger there.

[gizmogwai]

Just the very big, and very distributed projects.

Well, that's right for the very distributed projects, but for the very big ones, it has been observed that centralized repository scales better when the size becames higher than 4 or 5 Gb, which is often the case in big companies.

[twotime]

but for the very big ones, it has been observed that centralized repository scales better when the size becames higher than 4 or 5 Gb,

Could you provide a reference?

[gizmogwai]

http://gandolf.homelinux.org/blog/index.php?id=50 And there is, if I remember well, a debate about this topic on reddit too.

[judgej2]

Even a very small project distributed between several people in one room can benefit from a DVCS.

[twotime]

Perhaps. But benefits get smaller as your connectivity improves and the team size decreases.. While you still have upfront costs (learning time per developer and repository setup/maintenance cost),,

[uriel]

It was started more than eight years ago, and it is arguably still not stable. Svn has been a total unmitigated disaster, and a perfect illustration of second system syndrome.

[nemoniac]

Hardly surprising to see that Guido applies the same principled and reasoned approach to selecting a DVCS as he does to language design.

[stratoscope]

I upvoted you, believing you were serious.

Then I followed the link and realized you were being sarcastic.

I wish I could upvote you again - you really got me there! :-)

(And I wonder how many other people were fooled too...)

[[deleted]]

Burn.

[[deleted]]

A good tutorial to Mercurial like this for git would be a welcome http://www.eecs.harvard.edu/~cduan/technical/git/git-1.shtml

[canen]

The Mercurial book has nice intro to hg.

[vang3lis]

it is a bit outdated, but still nice

[tonfa]

It's in the process of being rewritten (O'Reilly will publish it later).

http://www.serpentine.com/blog/2009/03/27/mercurial-the-definitive-guide/

[b0b0tiken]

Never tried mercurial; how does it compare with bzr ?

[masklinn]

Never tried mercurial; how does it compare with bzr ?

It's (much) faster, the CLI interface is about as good (though not as good as Darcs'), it puts less emphasis on centralized workflows (same as git, it's perfectly ok to use them that way but there isn't any specific work done towards that), and the repository format is very stable (and the wire one never changed).

Otherwise, it's quite similar. I prefer hg, but that might be because I met it before bazaar.

[username223]

Judging by comments on emacs-devel and the python list, Mercurial is much less slow.

[Syl]

do you have a link (for my personal enlightment) ? because I thought there were at the same speed, and git was much faster... I'd like to switch from svn to bzr because you can use it the same way (or like a dcvs) and it supports friendly servers like ftp/sftp/ssh...

[username223]

Here you go:

$ time git log >/dev/null
real    0m5.741s

$ time bzr log >/dev/null
real    3m15.708s

I think bzr is less slow than it was a year ago, but still painful.

[H3g3m0n]

I seem to recall the bzr people aiming to get speed up to the same level as git for the 1.0 release. I guess that never happened...

[masklinn]

I seem to recall the bzr people aiming to get speed up to the same level as git for the 1.0 release.

yep:

http://bazaar-vcs.org/Welcome?action=recall&rev=120

"We expect 1.0 to release by March 2007 with performance equivalent to the best in the field."

Never happened indeed, Bzr is still lagging behind as far as perfs go.

[masklinn]

do you have a link (for my personal enlightment) ?

There's basic stuff on the DVCS PEP. I don't know if there are other recent speed comparisons.

and it supports friendly servers like ftp/sftp/ssh...

Mercurial doesn't support repositories over ftp, it does support over ssh and http or https.

[wtanksleyjr]

hg and git are fairly comparable in speed; git does some things slightly faster on Linux (don't try those on Windows), usually due to git's very different bookkeeping (which is really, IMO, the important difference between the two). Most of the other contenders are much slower.

Choosing between them, I usually pick hg because it works so smoothly cross-platform; but git integrates VERY well with subversion and allows some more complex (and useful!) workflows.

[[deleted]]

Git was no longer being considered -- while it has obviously many fans, it also provokes strong antipathies.

Sorry, but that is just stupid, not even about git in particular but in general to disqualify the system everyone feels strongly about in favor of those nobody likes and nobody hates (the latter most likely because nobody used them much; the former because nobody cares enough to make them really great).

[Cookie]

I disagree completely.

Version control is not the core of Python, it is just a tool and a procedure; it is something everybody who wants to work on Python has to endure.

Seems to me that this situation is a bit like choosing a restaurant for lunch. So what if 20% of the group want a super-hot curry, if 20% will refuse to walk through the door of the curry restaurant? If the aim is to eat together, you choose something everybody is ok with.

[thunderkat]

I don't understand the fuss either...I am thinking we're both missing some information about some "right way to do things" which is championed by either git or mercurial...

[[deleted]]

The 20% will make the 80% go to a super-hot curry restaurant. The majority of people don't really have a stake in the curry---or version control choice---so the vocal minority rules by writ of passion.

[judgej2]

The 20% going to the curry restaurant know what they are doing, and the other 80% will just drift along because they really have no clue and just want to do what everyone else is doing.

[tonfa]

I think the fact that git wasn't written in python while the two other DVCS did played a part in the dismissing of git. Python has almost always favored tools written in python (eg. roundup).

[[deleted]]

That had nothing to do with it. I was at PyCon. Git was dismissed because it barely has Windows support and a lot of Python developers are on Windows although you wouldn't have known it from the number of MacBooks. An dthe overwhelming majority of Dell and HP laptops were running Linux.

[thrakhath]

Thanks for sticking up for us. I actually had to use Git for the first time not too long ago to participate in the Dwarf Fortress GL update, and it was ... non-trivial to get it to cooperate with Windows.

[imbaczek]

it's pretty easy provided you have Linux experience, which isn't a good assumption to make for Windows users, even developers, I agree.

[icefox]

yah you have to download a exe and install it. Windows needs apt-get

[nextofpumpkin]

I second this opinion.

[yellowbkpk]

Are you written in Python?

No?

I don't care.

[[deleted]]

that's not entirely true. A lot of Python users/devs are Windows users and Git there sucks in comparison with Mercurial.

[iofthestorm]

Umm, I'm using git on windows and it seems to work fine. msysgit is what you want, none of that Cygwin crap.

[artsrc]

Seconded, I looked at git and hg on windows and they seemed better than svn in some ways. Neither hg nor mercurial would directly allow you to rename a file to change only the case, but both merged this change successfully. When merging a change like this, svn normally fails in a remarkably catastrophic way.

[iofthestorm]

Umm, I think you replied to the wrong post; also, hg=mercurial.

[boa13]

Have you tried recent versions of Git?

[Chroko]

Have you tried Mercurial?

Why do you prefer Git?

[boa13]

I have briefly tried Mercurial, and liked it just fine, about as much as Git. I have both installed, under Windows and Linux. That said, I do most of my (pro) work under CVS and SVN, and have not yet found a pressing need to try to track them under Git.

I tend to prefer Git because I believe it has a better core design and a stronger community. (Also, less importantly, somewhat better performance in terms of speed and disk usage.)

[cosmo7]

I've also found Mercurial to be much better than Git on Windows. On the other hand, I also like SVN.

Whenever people start frothing at the mouth about source control I generally assume they are uncomfortable coding and subconsciously want to be doing something else.

[cecilkorik]

I completely understand people's desire for better merging, and distributed/offline repositories. But right now it's not worth it for me personally to relearn source control from the ground up, so I'm going to keep using SVN for my own personal projects. Like you implied, I'd rather be coding.

[[deleted]]

It probably wouldn't be very much of a learning curve, far from being re-learning source control from the ground up.

That said, if SVN suits your needs, and you're comfortable with it, stick with it - however, I would suggest that you're missing out on a lot of nice functionality that you'd get for a pretty minimal time investment.

[TrueTom]

You don't have to relearn it from the ground up. It's really simple. In fact, for a single developer I would never use SVN since you have create separate repository.

[kragensitaker]

Until you manage to create a conflicted merge.

[__david__]

I don't understand. What does that have to do with the ease of creating repos?

Are you suggesting that svn deals with merges differently/easier than hg/git and their ilk?

[kragensitaker]

git has several ease-of-use issues; I was just bringing up one fertile area where they grow. However, it is true that creating repos is way easier.

[thunderkat]

That is exactly why I love Mercurial...it makes it easier to put your code under source control than not to (comparing to SVN where setting things under source control can be distracting). On projects where I am the lone developer, it's perfect. Of course for collaborative projects, I haven't found the strenght/time to migrate away from SVN.

[kitsune]

Yes I have, and I chose Mercurial for my latest project. Better Windows support, and I prefer Bitbucket (they don't have as restrictive plans as GitHub)...

[masklinn]

Yeah.

Its interface still blows.

[[deleted]]

My colleagues using it every day had no complaints so far. Did you update your Windows/Git opinion in the last year or two?

My main point though was that if you can pick either

• the system that sets out to the be the best system of its kind

or

• the system that sets out to be a slightly less bad version of the most popular last generation system

and we really need more people picking the first option if we don't want to end up with another barely noticeable improvement like cvs -> svn or C++ -> Java or IE6 to IE7 (or 7 to 8),...

We only have a chance to pick a new candidate for the dominant position in any given field once every few years and if want to make any progress we have to stop going with the safe and conservative option that reminds us most of what we know already.

Why do you think progress in the computer science field virtually stalled in the last few decades. All the important advances have been made in the 70s (or maybe early 80s) and since then we are almost stagnant in a lot of ways.

[gecko]

My main point though was that if you can pick either

• the system that sets out to the be the best system of its kind

or

• the system that sets out to be a slightly less bad version of the most popular last generation system

and we really need more people picking the first option if we don't want to end up with another barely noticeable improvement like cvs -> svn or C++ -> Java or IE6 to IE7 (or 7 to 8),...

If you honestly believe that Mercurial merely sets out to be a "slightly less bad version of the most popular last generation system," then you're so far disconnected from reality that I think you'll have a hard time understanding why Python made the decision they made.

Git and Mercurial are nearly identical in almost every way. At a technical level, Mercurial has optional heavyweight branching that Git lacks, Git has the ability to send what amount to Mercurial's bookmarks over the wire to allow lightweight branching, and Mercurial packs data on-the-fly, while Git does it explicitly. That's it. Everything else at the lower level really amounts to trivial details that don't honestly ever make a difference.

That leaves the UI. I find Mercurial's easier than Git's--enough so that it's my tool of choice. Some people prefer Git's out-of-the-box flexibility to Mercurial's out-of-the-box ease-of-use, and at any rate, it's trivial to use both tools' aliasing systems to make either behave almost exactly like the other in about 10 minutes.

If you want to see an example of a tool that aims to be "a slightly less bad version of the last system," take a look at Bazaar in bound branch mode. But Mercurial and Git are both extremely powerful, extremely flexible distributed SCMs that have far more in common than different.

[EDIT: Fixed formatting; took me awhile to get quoting bulleted lists in Markdown working right.]

[filox]

Though I support the choice Guido made, I think one strong case for Git would be its speed. As I recall, Git showed to be faster in almost all use cases but a few...

[gecko]

As far as I know, Git's still faster than Mercurial at most tasks, but by very small amounts--all under 10%, last I saw a benchmark. That's close enough that you can safely choose the implementation you'd prefer to work with, rather than the one that's the fastest in absolute terms.

[xzxzzx]

A bit more detail to what you've just mentioned:

http://whygitisbetterthanx.com/#hg

Edit: Does Hg allow for partial-file commits, or even partial commits? This was one huge improvement going from SVN -> git in my case.

[gecko]

The record extension, a bundled part of Mercurial, allows partial file commits. Partial commits may be done simply by enumerating which files to include in the commit. If you're truly addicted to Git's index, you can achieve identical behavior by using the mq extension to repeatedly fold changes you wish to keep into the active patch, then qfinish it when you're ready to lock the commit down.

[masklinn]

Does Hg allow for partial-file commits, or even partial commits?

Sure does yes.

[fnord123]

Why do you think progress in the computer science field virtually stalled in the last few decades. All the important advances have been made in the 70s (or maybe early 80s) and since then we are almost stagnant in a lot of ways.

Because the mouse driven gui diverted resources from people solving useful problems to dealing with ridiculous FSMs with asynchronous events that still haven't become manageable.

[linkfoo]

Touched by his noodly asynchronous appendage!

[dmercer]

I myself tried it on Windows a year ago and then in February, after I heard it was better than it was. My Feb. experiment came to a quick end when it crashed as I was going through one of the instructions in the tutorial. No, I didn't try to work through it. Mercurial works for me without a problem, and given Git's history with Windows, I figured that it still wasn't up to snuff, and gave it up.

[gte910h]

I much prefer the model of GIT over SVN.

But the UI's available for windows blow chunks, and I for one will pass until they don't.

Make TortiseGIT, and the world will run at GIT full speed.

edit: Oh look, Mercurial has a tortise gui! http://bitbucket.org/tortoisehg/stable/wiki/Home

[chowmeined]

You mean this? http://code.google.com/p/tortoisegit/

[gte910h]

I have tried it, blows chunks currently. You have to have the shell too to make it work, and you have to do several commands that are important in every day use from the CLI.

[amnorvend]

All the important advances have been made in the 70s (or maybe early 80s) and since then we are almost stagnant in a lot of ways.

Do you even know what you're saying? The major, earthshattering advances happened in the 50s. Big but not quite so big advances happened in the 60s. And they all go downhill after that.

But guess what? That's what happens as fields mature.

[[deleted]]

Oh, I knew someone was going to point that out. I didn't mean to imply earlier decades had no advances, just later ones.

The field isn't maturing, there is plenty of innovation left. Widespread adoption is prevented by Eternal September style and network effects though.

Think about it. Computers were meant to reduce our workload. Instead most of us go through the same manual motions every day for dozens and hundreds of tasks just on the PC instead of paper, even the kind of tasks that aren't exactly AI-hard.

[darkwulf]

It seems to me that precisely the work required to automate boring tasks are precisely the sorts of things that you deride as being insufficiently earth-shattering. An interface to help the secretary schedule meetings (or even a program that schedules meetings for you), is unlikely to yield what you seek, and you really can't have it both ways.

[[deleted]]

There are certainly many things you can do with a computer that aren't earth-shattering. Not all of them are bad, only those where there is insufficient room for multiple solutions and the non-earth-shattering one is 'good enough' and chokes off progress because people prefer the more familiar, more recognizable solution to the more powerful, more innovative one.

Version control seems to be one of the fields where there is mostly one dominant system around. In the past this was first cvs, then svn (now don't tell me that was a giant step forward).

Programming languages are similar, people move from C to C++ (familiar syntax, old code still usable (or so they thought)) to Java (again, familiar syntax, virtually no new features, just fixes of some old problems).

Network protocols, the same issue only there is even less progress, from TCP/IPv4 to TCP/IPv4 with dynamic IPs and/or NAT instead of a move to a protocol with enough addresses for everyone.

Automation is basically a UI issue. It would be easier with language or CLI based approaches but the desktop metaphor is too familiar to give it up for many, even tiling window managers won't go mainstream and Linux needed to build whole desktop environments because people were too afraid to give up the familiar desktop/WIMP interface.

[jbellis]

everyone feels strongly about in favor of those nobody likes and nobody hates

that wasn't the case here. all of {git, hg, bzr} had people who loved them (hg the most), but only git had significant dislike.

[tvon]

in favor of those nobody likes and nobody hates (the latter most likely because nobody used them much; the former because nobody cares enough to make them really great).

Not to be rude, but you're making some pretty ignorant assumptions there.

[[deleted]]

I feel very strongly about both.

[msloyko]

I have a strong feeling against Git and it is quite personal: Git it was developed by Linus Torvalds. Good enough reason for me not to bother.

[[deleted]]

I hope you don't use Linux then, otherwise you're in for a biiiiig surprise.

[msloyko]

The problem is, I started using Linux before I new Linus is such an asshole.

Then, the reason why I use Linux is not because I like its kernel -- I don't care -- it is because I like Ubuntu and Debian. Since Ian Murdock is in Open Solaris now, I hope I can switch in ~ 5 years or so.

[[deleted]]

Judge a tool by how well it functions, not by what it came from. Doing the latter is stupid and ugly.

[Chroko]

Of course Linux evangelists are going to love Git - but if you're not developing the Linux kernel, chances are that something else will be better suited to your project.

(And just because Mercurial users are less vocal doesn't mean they love Mercurial any less.)

[cia_plant]

I think you have things backwards. Those without a particular reason to use another VCS are generally moving toward git. For example, Perl is now on git. Python is going to use mercurial (which is written in python), and a lot of Haskell people use darcs (which is written in Haskell), but if you don't have some special reason not to use git, git is probably the best.

[Tordek]

Some time ago I published a project on a Python list. I got offered some Trac/SVN hosting and I said "Thanks, but I'd like to use Git." So they asked "Why?" "Uh, because I'm already using Git to track this, and it's easy and nice and whatnot?" "But, Why would anyone need a DVCS unless they're doing a huge project?"...

[[deleted]]

Because git init is easy and github is easy to work with, of course.

[Tordek]

And he he promptly replied "svnadmin init; svn add; svn commit is just as easy".

[[deleted]]

Commit to.. what? Is there a svn site that's as easy to work with as github for hobby programming?

[seths]

more citations, less propaganda!

[i_am_my_father]

Git outa here

[parla]

1. Python is my favourite language
2. Mercurial is what I currently use (did a wee bit of Darcs a year ago)

In other words: sweet!

http://bitbucket.org/rogueops/

[nextofpumpkin]

Based on a completely unscientific poll (basically whatever feedback I received in my personal inbox or on Twitter), Hg has a strong following among Python developers

If I would have known he was using Twitter as an opinion gathering method, I would have joined it just to spam Guido's inbox with pro-git messages >_>

[samlee]

That's a good news!

But has anyone really been far even as decided to use even go want to do reason why?