Comments on: Mercurial: a field report http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/ Samuel Tardieu's dual-sided blog Sat, 11 Oct 2008 09:46:14 +0000 http://wordpress.org/?v=2.6.2 By: Lionel http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3528 Lionel Thu, 01 Jun 2006 06:43:56 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3528 This is what I am experiencing whit DARCS. I was really pleased when trying it on my Linux box on a small personnal project. But when using it at work on a 4 guys project... some of the pull just never complete! I wondered if it was specific to the Solaris version, you answered. I'll give Mercurial a try. This is what I am experiencing whit DARCS.
I was really pleased when trying it on my Linux box on a small personnal project. But when using it at work on a 4 guys project… some of the pull just never complete! I wondered if it was specific to the Solaris version, you answered.
I’ll give Mercurial a try.

]]> By: Samuel Tardieu http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3510 Samuel Tardieu Wed, 31 May 2006 22:27:54 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3510 I just <b>love</b> Darcs, but it is painfully slow when working on large repositories (for the contest, I worked on the GCC+GNAT tree and the Linux kernel tree and Darcs would have taken ages to perform minor operations). Mercurial is blazingly fast. I just love Darcs, but it is painfully slow when working on large repositories (for the contest, I worked on the GCC+GNAT tree and the Linux kernel tree and Darcs would have taken ages to perform minor operations). Mercurial is blazingly fast.

]]> By: Lionel http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3509 Lionel Wed, 31 May 2006 22:23:30 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3509 Hi Sam, should I undestand that DARCS is no more the distributed SCM of choice for you? Hi Sam, should I undestand that DARCS is no more the distributed SCM of choice for you?

]]> By: Samuel Tardieu http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3490 Samuel Tardieu Wed, 31 May 2006 12:10:19 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3490 Not the development process, only the testing process. We only had one physical robot, so we couldn't test two branches at a time. It was easier to reintegrate changes before testing. At some occasions however, two developers changed different things and tested one after the other (we had a network access to the robot) as each test took a few seconds only. In this case, the changes have been reintegrated together. But this was not our common way of working. Not the development process, only the testing process. We only had one physical robot, so we couldn’t test two branches at a time. It was easier to reintegrate changes before testing.

At some occasions however, two developers changed different things and tested one after the other (we had a network access to the robot) as each test took a few seconds only. In this case, the changes have been reintegrated together. But this was not our common way of working.

]]> By: Thomas http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3489 Thomas Wed, 31 May 2006 12:08:10 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3489 OK, so actually the development process was completely serialized... OK, so actually the development process was completely serialized…

]]> By: Samuel Tardieu http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3487 Samuel Tardieu Wed, 31 May 2006 11:18:49 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3487 Those branches didn't diverge. When someone had some code ready, it was pulled by the person doing the tests on the robot at this time and tested right away. We had a policy on the central server not to push anything unless it compiled so that someone doesn't end up with a non-buildable version because of someone else. This was not enforced with technological solutions but could have been. In peer-to-peer mode, we were constantly working together (working in 21 hours shifts with about 3 hours of sleep per night while on-site) and when something was ready the developer asked the current tester (if different) to pull from his repository. Those branches didn’t diverge. When someone had some code ready, it was pulled by the person doing the tests on the robot at this time and tested right away.

We had a policy on the central server not to push anything unless it compiled so that someone doesn’t end up with a non-buildable version because of someone else. This was not enforced with technological solutions but could have been. In peer-to-peer mode, we were constantly working together (working in 21 hours shifts with about 3 hours of sleep per night while on-site) and when something was ready the developer asked the current tester (if different) to pull from his repository.

]]> By: Thomas http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3486 Thomas Wed, 31 May 2006 11:12:09 +0000 http://www.rfc1149.net/blog/2006/05/31/mercurial-a-field-report/#comment-3486 How did you select what actually ended up on board, with so many concurrently active branches being maintained? How did you select what actually ended up on board, with so many concurrently active branches being maintained?

]]>