Change VCS

From Inkscape Wiki
Revision as of 13:24, 17 March 2008 by Jiho (talk | contribs) (Initiated the page as a summary from the long email thread)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

With 0.47_Refactoring_Plan coming along, the idea was brought up to change for a new version control system which would ease refactoring in particular. This page summarizes various email threads. The project is to use a Distributed Version Control System instead of subversion.

As a general source of information, see

Why change?

Several things make a DVCS preferable to subversion for Inkscape:

  • speed
  • local commits allow to commit often
  • easier branching and merging, which is likely to be useful for feature work or Summer of Code work while the core is refactored
  • ... add your favorite feature from the wikipedia page above

This does not come without cost either:

  • someone must move the code to the new system
  • each dev must potentially learn a new system

Comparison of DVCS

Since past discussions seemed to lead to the concensus that the benefits outweigh the cost, the question remaining is which DCVS to use. The three main contenders are git, mercurial and bazaar. Here is a list of the their cost and benefits in the context of Inkscape development



  • faster: local commits: <1s vs 4s, push a new branch: instantaneous vs 35 min
  • ability to follow chunk of codes around, without relying on file names. Probably useful from a refactoring point of view
  • probably the fastest growing user base => many tools
  • TextMate bundle


  • git is designed with the Linux kernel's hierarchical workflow in mind (few 'push'ers to the central repos), so may require alteration in how Inkscape's workflow works (any dev can commit)
  • we would need to set up and administer this ourselves
  • revisions are indicated with SHA's rather than numbers
  • commands dissimilar to what we're used to with svn (e.g., no 'git update')
  • have to git add all modified files before committing them (or resort to a non specific commit -a)
  • no decent GUI (for windows?)

Mercurial (Hg)


  • tortoiseHG (remains to be evaluated)
  • TextMate bundle




  • already integrated in [launchpad]
    • Associating branches to bugs
    • Associating branches to blueprints
    • Changes state of bugs in LP when committing in Bazaar
    • Web interface for creating branches quickly and easily
  • supports renames (could be considered a - by git users)
  • supports bundling changesets
  • tortoiseBZR
  • Fewer commands - makes it easier to learn
  • Supports multiple workflows, including what we use for Inkscape (See
  • Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.


  • no support for line-endings conversion/convention enforcing (but such systems may create the risk of wrongly recognizing binary files)