A Django site.
December 16, 2008
» RFC: let’s make textual conflicts more personal

We’ve seen this pattern many times: you introduce version control to the team, and sooner or later someone encounters textual conflict. Less experienced users, such as HTML designers, copywriters, or even developers who are new to version control, tend to experience negative feelings, aimed towards Subversion and to you, by transitivity.

You carefully explain that all this time intelligent merging algorithm worked seamlessly, actually saving their time; that this is actual conflict between their changes and their colleague’s change. You track down that other person, and connect them both to work it out between them. They seem to agree, but I personally don’t have any illusion about what they think: that horrible “Subversion” beast patiently waited in its “repository”, and finally its time has come, and it mutilated their precious files with those horrible “>>>>>>>” symbols, dealing irrevocable damage, destroying hours of work. And it is you who should have abolished the beast weeks ago, yet you seem to somehow collaborate with it. Something is wrong.

I think that the problem lies in anonymity of conflict markers. Subversion shows them like this:


— .svn/text-base/sandwich.txt.svn-base Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32

Git shows them similarly. I propose that we add the necessary information about who did the change:

— .svn/text-base/sandwich.txt.svn-base Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine: DON'T PANIC. http://example.com/resolving.html
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32, added by mike at Tue Dec 07 11:00:00 2007

Of course, the information about who and when did the change is readily available from revision identifier, but the explanation could never hurt. It directs attention from the formless “Subversion”, or “Them”, to actual Mike, whom they could talk to. Second, the empty space could be used for some explanation, as set up by repository administrator.

If you like this idea — please, spread a word. Every version control system could be changed this way. And the change is almost purely cosmetic and I believe not very risky (though third-party tools could rely on conflict markers format too much).

What do you think?

October 6, 2007
» Mark Shuttleworth on renaming and merging

Mark Shuttleworth (of Thawte, Ubuntu, and Canonical fames) wrote four posts on rename tracking feature in version control systems, and its impact on merging as a social process.

Read at his blog:

Those posts caught a lot of attention back in June, but frankly it seems to me the issue is somewhat overrated (but nevertheless a recommended reading). Mark’s Canonical Ltd. supports the development of Bazaar. Bazaar has the discussed feature of merging with renames tracking. Git does not have it, but it has another argument in this discussion: huge merging traffic — Linux kernel development is all about merging, and the codebase is huge. So, I guess this feature is not that crucial: Linus is well-known by his uncompromising approach to tools.

» Ian Clatworthy: “The Future Is Adaptive”

Ian Clatworthy, one of the primary developers of Bazaar, has posted a series of articles on version control in broad modern context.

His primary thesis is:

Beyond market acceptance, there are 6 main criteria I consider when evaluating collaboration tools:

  1. Reliability
  2. Adaptability
  3. Usability
  4. Extensibility
  5. Integration
  6. Administration (including Total Cost of Ownership)

Read the whole series at:

Couple of memorable quotes:

Likewise, in the field of collaboration, I think there are 5 interesting numbers: 1, 2, 10, 100 and 1000. These numbers represent:

  • an Individual
  • a Partnership
  • a Team
  • a Company
  • a Community

[…]

As a young software engineer back in the early 90s, 10s of thousands of people woke up to cold showers in Sydney one morning because of a corner-case bug in my code controlling the off peak hot water system. That sort of event tends to have a life long impact on how one designs software!