Where the Hg transition stands

[edit 2010-01-09: links to mailing list archives containing latest discussion]

At PyCon 2009 it was announced that python-dev planned to move Python development from svn to hg. Well, just because we chose our distributed version control system (DVCS) does not mean that we were ready to hit the switch. For one I took a three month sabbatical from python-dev to get my PhD thesis proposal finished (which I did, thank science). Luckily Dirkjan Ochtman stepped in with PEP 385 and volunteered to handle the transition. At that point we thought that it would be a matter of creating a new sys.mercurial attribute (which we still need to code up), write up new developer docs on the workflow we expect to use, and then do a high fidelity conversion of the revision history to hg and then flip the switch.

But then bloody line endings wielded their ugly heads. While I was writing PEP 374 and evaluating the three leading DVCSs I was under the impression that the win32text extension for hg did what we needed. No one every spoke up saying otherwise while the PEP was out for discussion or anything so I simply didn't worry about it.

But then Mark Hammond came forward and said we had a problem. Obviously Mark has experience working under Windows, but he also has experience with hg thanks to his work with Mozilla. From Mark's experience it seemed that no matter how careful people were that the line endings would get messed up in the repo, and that just isn't acceptable. Martin v. Löwis then came forward and pointed out how this was not acceptable as well. Turned out that win32text didn't properly protect from mistakes at it is user-specific, not repo-specific. This was not what we wanted; svn's svn:eol setting is really handy and has turned out to be great to have around.

So this led to a long discussion over what an hg extension would look like that would mimic what svn:eol did. This led to the idea of the hgeol extension. In a nutshell we would end up with an extension where we had a .hgeol file that was version controlled. It would specify how files should be checked out (e.g. native for the OS, \n, \r\n, or binary) and make sure that no checkins are going to lead to bad line endings. The design can be found in the Mercurial wiki (be aware it is a wiki page so some people have simply dumped ideas in there). The latest discussions on various Mercurial mailing lists can be found here and here (search for [eol] to find the relevant threads).

Martin Geisler, a Mercurial contributor, in the end up picked up the torch and went a good distance. He has his in-development code at bitbucket. But the work is not finished. Martin has to work on his PhD thesis, so he has stopped active development for a few months. That means those that are motivated to help would be greatly appreciated. At this point what is really needed is making sure the code is robust and that is works as desired. That means making sure the tests work and the results are as expected on both UNIX (this includes OS X) and Windows. It also means making sure that the test suite is thorough enough to cover all the possible problems that might come up during development.

This inherently helps test to make sure that the design covers what is needed. One of the reasons this entire line ending problem has not been solved before is most of the Mercurial dev team is either not on Windows or use editors that know how to handle line endings properly (I'm looking at you with the evil eye, Visual Studio). So while we think the current design works, we don't have any real-world usage yet. So some pounding on the extension with a repository that someone actually uses would be great to make sure we didn't miss something.

In other words we would appreciate help pounding the heck out of the extension. Both running the tests, making sure the tests are thorough, and using the extension with an actual repository that gets used on a regular basis would be highly appreciated.

Dirkjan is coming to PyCon 2010 so I would expect at least a lightning talk on this. There is also hope between Dirkjan and I that we can see this transition happen in the first half of this year, but that really depends on the hgeol extension getting into a good enough place that we are not isolating Windows developers.

Why Python is switching to Mercurial

Starting at PyCon 2008 thanks to Barry Warsaw and the Bazaar team I started thinking about moving Python over to a distributed version control system (DVCS). While I wanted to get offline commits for the benefit of non-core developers along with easier merging from 2.6 to 3.0 (ah, the days when there are only three branches under development), I knew that would not necessarily be enough of a reason for others to switch.

Come October I started a PEP for switching off of svn to a DVCS. Originally it was going to be hg vs. bzr, but enough of an outcry on python-dev led to me to relent to adding git to the PEP. With the list of DVCSs decided I began writing up common use cases that I and other developers have come up against in developing Python. I then had a representative for each DVCS fill in the PEP with the best solution to the use case (who I am grateful to for helping). This all became PEP 374.

And for me that's when the stress began. I was being bombarded on all sides on this pretty regularly. I quickly realized that choosing a DVCS was like choosing a code editor; it's a very personal thing for a lot of people. Plus I forget how big Python is now; when what I was doing hit the Net I ended up talking with developers from all three DVCSs which I didn't expect.

Time past and I tried to absorb all three DVCSs as much as I could, although with my internship and trying to finish importlib for 3.1 I only had so much time. I ran a survey of the core developers where I asked them to rate the three DVCSs as either better, equal, or worse than svn if they felt they had enough experience to have an opinion.

Based on the results of that survey where git was clearly the most disliked tool of the core developers, having the weakest Windows support, and not being implemented in Python, I decided to eliminate git from the running and announce its elimination at the first lightning talk at PyCon.

When I arrived at PyCon pretty much everyone asked me about the DVCS PEP. People wanted to know how it was going, who was going to win, and giving me support/pity for what I was going through. Guido noticed this and decided to end my misery by saying he wanted to make a decision by the end of PyCon. I said I was fine with that as one was already about to be eliminated and I knew my personal preference at that exact moment aligned with Guido's.

So I did my lightning talk eliminating git. Luckily that went well with only about two people telling me directly they disliked the decision.

But the more telling thing was what everyone else told me after that lightning talk. I ended up with a surprisingly large number of people telling me -- including core developers -- they wanted, preferred, or guessed that hg would now win. Now the guesses could be explained away by Guido having publicly stated he likes hg, but to me the amount of people telling me they wanted hg to be chosen was surprisingly large. And honestly no one told me they preferred bzr (although no one said I better choose hg over bzr either).

So Monday morning came around and I walked into the sprint. I asked Guido if he was ready to make a decision. He said yes, we both said hg, and so Guido tweeted the decision before telling python-dev that we chose Mercurial.

There has been a lot of speculation as to why Guido pronounced the way he did. On Twitter Guido said to read PEP 374 for the reasons. Since I helped write my PEP my reasons are reflected in the PEP.

Obviously community preference as shown at PyCon played a role. No one wants to choose a DVCS that causes the community to not want to contribute to Python. And I would never choose a VCS that would cause Guido to not want to work on Python. Some people seem surprised that something non-technical played a role, but ignoring social issues is to ignore how much open source is a social phenomenon. And we are not the first project to take social preference into consideration: I know both GNOME and Pinax chose git because their developers preferred git.

And there are technical reasons. Having hg being faster than bzr by 2x to 3x does matter to some extent. No one wants to cause someone to not contribute because they didn't want to wait for a checkout. And having personally experienced long checkout times because of a subpar connection to a specific server I know this can occur. The performance margin between hg and bzr is within reason typically and is not a flat-out deal-breaker, but it doesn't help either.

Bazaar also has its short timespan of format stability working against it. The tool has changed its format at least three times based on what the man page says (1.0, 1.6, and 1.9). Mercurial, on the other hand, has been stable since I think it went public or near that time. They take great pride in the fact they have not changed it. And that stability more aligns with python-dev's sensibilities regarding stability.

Stephen Turnbull's explanation of why on the bzr mailing list is also a good explanation of why we chose hg. Basically no one is saying bzr is bad, just that hg is a better fit for our needs on python-dev.

But the thing I really love about having made this decision -- other than I don't have to stress about this anymore -- is that everyone seems to be flat-out happy we made a decision to switch as well. Once again the Python community stands out as being friendly and understanding about stuff like this with no one really seeming to be upset that we made the decision we did.

As for when the switch will happen, I don't know. We are hoping by summer, but that is just a hope at the moment. We have to figure out the best way to convert our history as well as what workflow we want to have.

Benchmark numbers for DVCSs on Python's repository

Robert Fendt benchmarked Python's repository on various DVCSs. It confirms my numbers that Bazaar, Mercurial, and Git are all fast enough for our needs.

The adventures with Git continue

Neil answered my questions (as did people who left comments on my last post; thanks) and so I learned a few things. One, is if you want to see what is going to be committed to a svn repository, use ``git log git-svn..`` (do notice the trailing dots!). You can also use ``git show`` to get a diff of the last commit. To see the differences between HEAD and the current state of the files you use ``svn diff HEAD^`` (the "^" means "previous", and I believe you can just keep tacking those on to go as far back as desired).

OK, so now I can confidently see what I will be pushing to Python's svn repository. So I do ``git svn dcommit`` and find out that someone has changed Misc/NEWS and that I need to merge first. OK, so I do ``git fetch git-svn`` followed by ``git merge git-svn``. Oops, that last command was not the right one.

Unlike other DVCSs, Git prefers you use "merge" when you have not changes and "rebase" when you do. So I messed up by not using ``git rebase``. Fine, screw-ups happen; I just need to resolve the conflicts now in Misc/NEWS, right? Heh, I wish.

I fix the file and try to do ``git resolve Misc/NEWS``; turns out that is not a command. Fine, I try ``git commit Misc/NEWS``; can't do a partial commit during a conflicted merge. I try ``git commit``; "error: Error building trees". What is up with this program!

But I am determined to make this work, so I continue to poke around. I find ``git reset``. Turns out I want ``git reset --hard`` to ditch the changes. I do that, do the proper "fetch; rebase" dance, fix the conflict, do a ``git add``, and then continue the rebase. So now everything seems fine.

But then I still can't commit. When I run ``git svn dcommit`` it complains that Mac/IDLE/Makefile.in is out of date:

Committing to svn+ssh://svn.python.org/python/trunk ...
 M Mac/IDLE/Makefile.in
Transaction is out of date: Out of date: '/python/trunk/Mac/IDLE/Makefile.in' in transaction '65108-1' at /unix/bin/git-svn line 461

The joke of it all is that I didn't touch that file, nor does Git say I touched it. Looks like git-svn is just deciding to screw with me at the wrong time.

First impressions of Git

Neil Schemenauer has set up a read-only Git mirror of Python's svn repository. I decided to give it a try by using a Git branch for the removal of the sunaudio module. Damn did I have to get a lot of packages to build the documentation. It was pretty ridiculous how much of a hassle it was to get Git installed under OS X in a directory of my choosing. MacPorts didn't work thanks to a segfault being triggered by some Perl package and APR. And then the binary packages only install in a single location. So I did it by hand, but it took a lot of compile-find_missing_package-repeat work to get everything built, even when the configure script checked for things! The build process and the dependencies could definitely use some work.

I think everyone knows that Git is very fast and I agree with that. Doing the initial checkout, local branching, local checkins, diffs, etc. were all very fast. I only had one performance issue where I ran ``git-svn show-ignore`` and it did some indexing thing that took a couple of seconds.

One thing that did throw me is the difference between a clone and a branch. Turns out that a branch is done in-place, while a clone makes a new copy. I am used to using a "cloning" approach to development where I have multiple checkouts, but I decided to try "branching" instead. Once I learned that ``svn branch`` lists your branches and ``svn checkout`` switches in-place, I was good to go.

I did my work, ignoring the fact that a bunch of files were being listed as untracked (I will create a .gitignore file another time). I actually forgot I was working under git, so I didn't do a bunch of small commits, just one big one for my work.

And that is when Git's way of things threw me a little. I wanted to diff between commits, but those commit numbers are really long. I figured out I can diff against the master branch by specifying the branch name, but how do you diff against a specific commit version?

I also wanted to commit from Git to svn, but when I ran the command a ton of output came spewing out from my terminal. I didn't like that so I killed the process. When I ran ``git-svn show-ignore`` I realized the output was rebuilding something. Having an actual ``git gc`` command still strikes me as odd. But I still don't know how to tell what ``git svn dcommit`` is actually going to push to the server. Plus I don't know how to diff between specific commits without pasting in those huge commit numbers. I guess there are no simple, symbolic commit names?

Anyway, Git seems very powerful, but still slightly quirky. I am going to reserve judgment until I have had a chance to push changes to svn and used it some more. I also need to see if I can get svn 1.5 working for me again (the build from MacPorts keeps crapping out on me) so I can try the bzr-svn plug-in and have both DVCSs on more equal footing.

Now using Bazaar branches on code.python.org for importlib stuff

I have been doing my importlib work (both the library and bootstrapping in 3.0) in local bzr branches on my machine. But today I finally decided to push them up to code.python.org. If you go here you will see the two branches I created. Ignore the fact that Apache lists the directories as empty; everything is kept in a .bzr directory.

Idea on how to do collaborative work off of a svn checkout using hg or bzr

I am collaborating with someone on a patch for Python. It isn't a huge amount of new code, but it does touch several files. We could create a new branch in svn to do the work in, but that just seems so bloody heavy-handed.

So I thought about how I could us hg or bzr for the collaboration work. First you have to take your svn checkout and initialize it for hg or bzr. That's not big deal as it just creates some directory. You then add any initially modified files you have and commit. From there you create a branch into another directory. You then zip up that branch and send that to the person you are collaborating with. They can then unzip the branch into a svn checkout they have and thus you both start off of the same initial repository.

With hg you can send changes back and forth using bundles. You probably want to tag the revision you last updated externally to so as to make sure your bundle contains all changes you initially made. Then just send the bundle to the other person and they can unbundle it. That lets you do simultaneous development with offline commits and merge resolution.

With bzr I think you have to stick with straight diffs. Bzr's bundle command is undocumented and the output it created that I applied using ``bzr merge`` said there were no changes when in fact there were. And I couldn't figure out how to get the 'send' command to output to a file instead of trying to send an email. But diffs should work nonetheless.

git-svn doesn't allow for compiling a fresh Python checkout

Always being one willing to try new ways of making my coding life easier, I looked into svn support by Mercurial, Bazaar, and git (didn't look at svk as I don't like the whole depot thing). Since hgsvn doesn't support a way to push changes back to the svn repository and bzr-svn requires running against svn 1.5 which is not even released, I decided to try out git-svn.

So finding consistent instructions on how to use git-svn was a slight pain. Everyone used different commands and didn't always flat-out state what each step was doing. But after some searching I realized I wanted ``git-svn init __svn_url__`` to create an initialized, but empty, git repository. Following that, I ran ``git-svn fetch -r __svn_revision__`` in the git repository directory to fetch a svn checkout at the revision number. Finally, running ``git-svn rebase`` updates the checkout to HEAD (which took hours even though I only downloaded the history as far back as the start of 2.5 work). It also turns out that ``git-svn clone`` combines these steps into one.

With that done I ran ``git gc`` to "clean up" the git metadata. That also took a while.

Now I had a checkout of Python under git with history as far back as when 2.5 development started. Great, now I just needed to compile the checkout so that I could use it the next time I had to do some development.

Whoops, you can't compile. Why is that? Well, it turns out that sys.subversion requires that the $HeadURL$ autoprop from svn be replaced (see Python/sysmodule.c:932 as well as the svnversion_init() function). If it isn't set a Py_FatalError() call is made. Since this happens during the initialization of the sys module there is no way to ignore it. So unless I am willing to patch it so that sys.subversion does not require svn and it instead set to some null value if svn isn't used for the code or I explicitly add git support then you can't compile Python if you used git-svn to check it out.

So no git repository for Python for me. Oh well.

New tracker is up!

bugs.python.org is now live and the official tracker for Python! You can read the announcement here.

Another (unscientific) comparison of Mercurial and Bazaar

After my rant on how many version control systems (VCSs) there were and the lack of good Eclipse plug-ins for them, I looked at the number of visits to my very unscientific comparison of Mercurial and Bazaar I did back in November 2006. With over 5,300 visits to that page, and after having a very rough month personally and thus needing to do something "relaxing", I decided to do another review.

I took a different approach this time when implementing the tests. The biggest thing I did was run any server needed locally and connecting through 127.0.0.1. Using a local sshd with public/private keys made the tests go much faster compared to last time. I also generated shell scripts from a template to execute the playback steps instead of a Python script that used subprocess as it made debugging as easy as visually checking out the shell script itself.

In terms of what I tested, here are the steps I had every VCS go through:

1. Initialize a Main repository.
2. Add an empty file named 'A'.
3. Commit 'A'.
4. Add a single line to 'A' and commit.
5. Create a directory named Local that held a new repository named Checkout that did a remote branch/clone of Main (also used Local as a shared repository for some tests; discussed later).
   
6. Create an OtherPerson clone/branch of Main through remote means.
7. Add a second line to 'A' in OtherPerson and push to Main.
8. Pull from Main the change to 'A' into Checkout.
9. Edit the first line of 'A' in Checkout and generate a patch, and then push the change to Main.
10. Locally branch off of Checkout to create Branch (which is also in the Local directory).
11. Create a new file named 'B' in OtherPerson and push to Main.
12. Edit the second line in 'A' in Branch.
13. Pull 'B' into Checkout.
14. Merge 'B' into Branch.
15. Push change in 'A' to Checkout and then to Main.
16. Pull change to 'A' in to OtherPerson.

Six revisions total (according to Bazaar at least).

In terms of testing I ran using Python 2.5.1 (no pydebug). Both hg and bzr were checked out of their stable development branches (hg as version 5cbdea5735f4 and bzr as revision 2644). For each test I ran it once without counting it to generate any needed .pyc files. I then ran the test three times in a row and recorded the fastest real time as reported by /usr/bin/time.

For measuring the disk space I ran ``du -c -h`` on the Local, Main, and OtherPerson repositories and recorded the reported amounts.

While the tests were running I didn't touch my machine. But I did not try to minimize background processes, etc. I can only do so much in the name of fun. =)

In terms of the various tests I ran they are:

hg

Mercurial over SSH.

bzr

Bazaar using the SFTP protocol for remote pushes and pulls. This is what seems to be the most prominent way to securely connect to a remote bzr branch other than over HTTP as shown in the Bazaar manual.

bzr checkout

Bazaar using a checkout over SFTP. This seems to be for more svn-like development.

bzr ssh

Bazaar using the bzr+ssh protocol.

bzr serve

Bazaar using the bzr protocol and a server running as ``bzr serve --allow-writes``.

bzr shared

Bazaar with a shared repository.

The things that were timed are pretty self-explanatory. For the remote cloning/branching I just call it cloning even though that is not necessarily the command used. And for instances where two commands are needed to complete a specific step (e.g., Mercurial requiring a pull and update to apply changes from a remote branch), the total time is reported.

And everything is measured in seconds.

• init
• hg : 0.231
• bzr : 0.891
• bzr checkout : 0.891
• bzr ssh : 0.873
• bzr serve : 0.834
• bzr shared : 0.860
  
• add
• hg : 0.294
• bzr : 0.701
• bzr checkout : 0.711
• bzr ssh : 0.696
• bzr serve : 0.686
• bzr shared : 0.703
  
• commit
• hg : 0.375
• bzr : 0.975
• bzr checkout : 0.973
• bzr ssh : 0.976
• bzr serve : 0.958
• bzr shared : 0.991
  
• remote clone
• hg : 1.202
• bzr : 1.990
• bzr checkout : 1.981
• bzr ssh : 2.791
• bzr serve : 1.664
• bzr shared : 2.005
  
• remote push
• hg : 0.859
• bzr : 1.723
• bzr checkout : 1.560
• bzr ssh : 2.193
• bzr serve : 1.000
• bzr shared : 1.671
  
• remote pull
• hg : 1.226
  
• bzr : 1.713
• bzr checkout : 1.891
• bzr ssh : 2.253
• bzr serve : 1.052
• bzr shared : 1.772
  
• local clone
• hg : 0.399
• bzr : 1.217
• bzr checkout : 1.131
• bzr ssh : 1.200
• bzr serve : 1.223
• bzr shared : 1.131
  
• merge
• hg : 0.691
• bzr : 0.964
  
• bzr checkout : 1.018
• bzr ssh : 0.980
  
• bzr serve : 0.934
• bzr shared : 0.928
  

And here are the disk usage stats:

• Local
• hg : 96K
• bzr : 168K
• bzr checkout : 164K
• bzr ssh : 168K
• bzr serve : 168K
• bzr shared : 136K
  
• Main
• hg : 40K
• bzr : 72K
• bzr checkout : 72K
• bzr ssh : 72K
• bzr serve : 72K
• bzr shared : 72K
  
• OtherPerson
• hg : 52K
• bzr : 84K
• bzr checkout : 80K
• bzr ssh : 84K
• bzr serve : 84K
• bzr shared : 84K

Once again Mercurial is faster and uses less space when compared to Bazaar. If you do use Bazaar it seems that using a shared repository and a smart server is the best approach (assuming there is no security issues with doing so as I don't know if there are any authentication mechanisms in place for the server when doing a push).

But one thing to consider is robustness of various operations. If you read Mark Shuttleworth's blog enties on VCSs (here, here, here, and here), it would seem to suggest Bazaar might be as slow as it is and take up as much space as it does because it is trying to be lossless. I don't know how Mercurial's approach differs so I have no clue if this is a valid defence for Bazaar's performance.

Probably my biggest knock against either VCS is Bazaar's documentation. The official doc is two versions behind the current release. Even if nothing changed, at least bump the version number up. Plus finding the docs for the various remote protocols was non-obvious. And lastly, the install docs say Paramiko (probably the reason SSH performance is so bad) does not require PyCrypto, but that is completely false; you can't even import Paramiko without PyCrypto.

In terms of friendliness, both projects are great. I have interacted with core developers on both teams and they have always been helpful. The Bazaar group especially has been great as they have taken the time to comment on my blog any time I have had any issues with Bazaar.

And the usual caveat must be made that neither project is at version 1.0 yet.

In the end, if your project is small you can probably live with either project. Bigger ones, though, might want to take a look at Mercurial. But obviously do your own testing by importing your code into both VCSs and see what the performance is like for your common needs.

A little rant on version control

This is a two part rant. First part is about why there are so many different version control systems (VCSs). The second is on trying to get them to integrate into Eclipse. Because this is a rant realize it is being done because something has ticked me off so I am not exactly in a calm, rational mood so take what I say here with a big grain of salt.

So, in the beginning (i.e., when I started programming earnestly), there was CVS. It got the job done, but boy did it suck to have individual revision numbers per file. And want to move a file? Well, forget that unless you had server access.

Then came Subversion which fixed both of those issues. That made centralized VCS good.

But all the while there was this idea of a distributed VCS as started by Arch. It didn't count for much as the idea of a distributed VCS just didn't fit my brain at the time and it was supposed to be a pain to use.

But that little distributed VCS idea has caught on. Witness the number of modern, distributed VCSs one can consider: Bazaar, Mercurial, darcs, Monotone, and Git (and Codeville which I just learned about today but I don't know how stable it is). Hell, even Subversion gets into the game with SVK. And I believe the Subversion developers are planning to add distributed abilities in some future version.

But why can I rattle off nine popular VCSs? Do we really need that many? I don't think we do. Considering my Mercurial vs. Bazaar shoot-off still gets a bunch of hits even though its now outdated (I need to rewrite it so that it takes advantage of a local repository over SSH by launching a local sshd instance) I think other people are having a tough time like me trying to choose a VCS that is easy to run for their own needs. The existence of a tool like Tailor also seems to show that there are too many options out there.

I just hope that some consolidation comes soon in the realm of VCSs as having to keep multiple VCSs installed is a pain, let alone trying to choose the right one.

And this segues into my bitching over getting local version control working under Eclipse. I tried to get Mercurial and Bazaar working for Eclipse, but both plug-ins had issues (but both claim alpha or less quality so that's fine). But having to run a local svn repository just to get IDE support seems rather heavy-handed. Plus figuring out how to get the damn thing working was a pain (trick was to use svnadmin to create a repository in my Eclipse workspace and then do Team -> Share to add my existing project into the repository).

But it makes me wonder what kind of plugin support I could have in Eclipse if some consolidation occurred. Then again, Eclipse's heavy-handedness in terms of requiring a plugin to play nicely makes the barrier of entry kind of high (especially if the VCS developers aren't Java coders by nature). Makes me wish I could use Vim easily for AspectJ development.

Bah. So, in summary, I wouldn't mind some consolidation in the VCS arena so the talented VCS guys can work towards three killer VCSs (Subversion, Mercurial or Bazaar, and Git are my choices). And then they can band together and make sure my life doesn't suck in Eclipse when I am forced to use the editor. =)

bzr/hg performance comparison with newest versions

Actually, the numbers come from bzr .13 and a checkout of hg that I updated after 0.9.3 came out. The performance numbers straight from my comparison script are below. Do realize I did not update the software on my server. I am only doing this because someone asked.

+ Create/initialize the main repository
- time
* bzr : 1.38 sec.
* bzr_shared_repo: 1.23 sec.
* hg : 0.60 sec.
- disk usage
* bzr : 0 KB
* bzr_shared_repo: 0 KB
* hg : 0 KB
+ Add the test files
- time
* bzr : 2.17 sec.
* bzr_shared_repo: 1.85 sec.
* hg : 1.07 sec.
- disk usage
* bzr : 397 KB
* bzr_shared_repo: 397 KB
* hg : 391 KB
+ Commit the adding of the test file
- time
* bzr : 6.86 sec.
* bzr_shared_repo: 7.78 sec.
* hg : 1.82 sec.
- disk usage
* bzr : 728 KB
* bzr_shared_repo: 434 KB
* hg : 587 KB
+ Commit an added line to the test files
- time
* bzr : 9.15 sec.
* bzr_shared_repo: 11.00 sec.
* hg : 1.85 sec.
- disk usage
* bzr : 753 KB
* bzr_shared_repo: 433 KB
* hg : 599 KB
+ Initialize repository on the server
- time
* bzr : 11.72 sec.
* bzr_shared_repo: 10.12 sec.
* hg : 2.89 sec.
- disk usage
* bzr : 753 KB
* bzr_shared_repo: 433 KB
* hg : 599 KB
+ Push local repository to server
- time
* bzr : 34.26 sec.
* bzr_shared_repo: 35.78 sec.
* hg : 2.74 sec.
- disk usage
* bzr : 753 KB
* bzr_shared_repo: 433 KB
* hg : 599 KB
+ Pull from server to create a pristine branch
- time
* bzr : 28.72 sec.
* bzr_shared_repo: 8.47 sec.
* hg : 3.72 sec.
- disk usage
* bzr : 1498 KB
* bzr_shared_repo: 1179 KB
* hg : 1195 KB
+ Clone local repository
- time
* bzr : 9.32 sec.
* bzr_shared_repo: 5.39 sec.
* hg : 1.97 sec.
- disk usage
* bzr : 2244 KB
* bzr_shared_repo: 1605 KB
* hg : 1790 KB
+ Commit change in cloned branch
- time
* bzr : 12.38 sec.
* bzr_shared_repo: 13.09 sec.
* hg : 2.57 sec.
- disk usage
* bzr : 784 KB
* bzr_shared_repo: 438 KB
* hg : 615 KB
+ Push changes to server
- time
* bzr : 27.53 sec.
* bzr_shared_repo: 26.01 sec.
* hg : 2.88 sec.
- disk usage
* bzr : 784 KB
* bzr_shared_repo: 438 KB
* hg : 615 KB
+ Pull from server to update pristine branch
- time
* bzr : 22.18 sec.
* bzr_shared_repo: 8.99 sec.
* hg : 5.09 sec.
- disk usage
* bzr : 787 KB
* bzr_shared_repo: 439 KB
* hg : 615 KB