Change VCS

This page is outdated. It is kept for historical reasons, e.g. to document specific decisions in Inkscape development.

With version 0.47 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 http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

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

Git

Good

• 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

Bad

• 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')
• no decent GUI (for windows?)

Not sure

• have to git add all modified files before committing them or resort to `git commit -a`. This is shift from the SVN way of doing things. However with single files, `git commit filename` is equivalent to `svn commit filename`. Plus, with multiple files git basic workflow is probably more powerful: it allows to add a set of files to a commit and only then to actually do the commit. The same thing with svn (or other similarly behaving systems) requires to write a long list of files in a single command line.

Mercurial (Hg)

Good

• tortoiseHG (remains to be evaluated)
• TextMate bundle

Bad

Bazaar

Good

• 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 bundling changesets
• tortoiseBZR
• Fewer commands - makes it easier to learn
• Supports multiple workflows, including what we use for Inkscape (See http://bazaar-vcs.org/Workflows)
• Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help.

Bad

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

Not sure

• A good point is that bazaar supports renames but it could actually be considered a "Bad" by git users

Links

• Bazaar Why
• Bazaar in Lanunchpad
• Bazaar workflows
• Google talk videos on GIT [1] [2]
• SVN Course