Language Selection

English French German Italian Portuguese Spanish

DVCS Round-Up: One System to Rule Them All?--Part 1

Filed under

A recent development in the field of version (or revision) control software is the emergence of distributed systems. These discard the notion of a central repository where all project history is kept, and replace it by a network of several repositories that are synchronised regularly. In this model, a developer has a complete repository on his hard disk, which is synchronised with the “outside” whenever deemed necessary. This way one can commit early and often, without fear of breaking the others' code, and it also reduces network load as it does not need a network connection for every small change. In practise, of course there will be a central repository after all, but this is a decision made by the developers and not dictated by the system.

Working distributed has other advantages, too. For example, backups become a no-brainer, since every developer has the complete project history. The classic dilemma of who should have write access to the main project repository becomes significantly less problematic, since the maintainers simply pull the changes from a few persons they trust, which in turn (hopefully) have done likewise beforehand. Linus Torvalds referred to this as a “network of trust,” which is actually the same principle for any security and encryption software.

So, while distributed version control has several advantages, one problem remains: we have to choose one that (hopefully) fits our needs. At the time of this writing, at least half a dozen systems compete for the developers' affections, and this series will hopefully provide you with a basis for your decision.

In this review, we will take a look at six different revision control systems. Namely these are git, Mercurial, darcs, Monotone, Bazaar (which is used by the Ubuntu project), and SVK (which is based upon Subversion). All six systems are distributed, and we will take a look at the different workflows supported (or enforced) by them.

More Here

More in Tux Machines

Leftovers: Gaming

Leftovers: KDE

  • LUKS support in KDE Partition Manager
  • Kate 16.04 on Windows (64bit)
  • The future of KApiDox
    I’ve been working hard to enhance KApiDox. I’d like to come back on what it is for, what I did and what I see for its future.
  • Danbooru Client 0.6.0 released
    It offers a convenient, KF5 and Qt5-based GUI coupled with a QML image view to browse, view, and download images hosted in two of the most famous Danbooru boards ( and
  • A KMail Breakthrough.
    This tells the story of how I finally managed a successful transfer of email data from KMail version 1.13.6 to version 4.11.5. It is a non-technical essay exploring the obstacles I encountered, my options, and the methods I used to achieve my aim. It was written partly to give the information, but also with the hope that readers will both enjoy and be amused by the story of the "battle of KMail" that was ultimately won against "incredible odds". Links to the earlier articles discussing problems with KMail 4x are given at the end.
  • [GSoC] Kdev-Embedded, Debugging and programming embedded systems
    The actual embedded system word depends on closed-source IDEs and libraries, with high monetary value and deprecated functionalities. Programmers that would like to use ARM based boards without paying for an IDE will have problems setting up such development ambient and synchronized toolkits. The main idea of this project is to provide a plugin integrated with KDevelop to help the debugging and programming process of embedded systems like AVR, ARM and x86 based boards.

Red Hat and Fedora

Leftovers: Ubuntu