For the Cafu Engine project, we have almost from the very beginning used
Subversion as our version
control system, and Trac as the bug and issue tracker.
Both systems have served us very well in the past, and in fact until
today there is nothing fundamentally wrong with either of them.
However, over the years, the requirements of developers and users have evolved, as has the Cafu Engine and available version control systems. Increased flexibility and ease of work for everyone who participates in the Cafu Engine are more important than ever.
With DVCS – distributed version control systems – being widely spread and well known today, most prominently Mercurial and Git, and with related hosting and collaboration platforms such as Bitbucket and Github readily available to everyone, it's time for change.
In this post I will summarize the current state of affairs regarding the migration of Cafu to Mercurial or Git.
Why DVCS?
Why should we migrate from Subversion to Mercurial or Git at all?
What are the goals?
Mercurial or Git?
The internet is full of related debates already. As I do not want to start another one, I'll be brief:
In my opinion, Mercurial is easy to learn, well documented, and powerful enough for 99% of all use cases and users. For new projects with no pre-existing history, Mercurial is my clear favorite.
Git is technically more sophisticated, but comes with a horrible command-line interface. These days it is easier to learn than it used to be, but developing a proper mental model and becoming a confident (admin) user still takes a very big effort.
A fair and competent opinion about Mercurial and Git was expressed by Sinbad, the founder and former lead of the Orge3D project. I much agree with his points in this discussion. (Continue reading on the subsequent pages 13 and 14, where he also links to his detailed review and comparison.)
Besides studying all the existing, prevalent sources, during the last few weeks and months I also spent huge amounts of time with evaluating both Mercurial and Git myself: The minimum that I wanted to accomplish was gaining a good understanding of each system, import the existing Cafu Subversion repository, and run some real-live tests that resemble daily routine Cafu development.
My opinion about Git:
Despite my original preference for Mercurial, I must say that I spent more time with Git (maybe because it took me three printed books to get a good understanding of it), so probably in the end I was more biased than I now like to admit.
As we will see later, the initial importing of the Subversion repository turned out to be the crux. After a long battle, it turned out that I was able to complete the conversion to Git in exactly the clean, complete and careful way that I wanted, whereas my attempts at converting to Mercurial were unfortunately much less fruitful. Things had probably gone better for Mercurial if I had invested more time into it, but then I have still no idea how I could have done with Mercurial what I did with Git.
With this experience, I eventually chose Git to proceed with the next steps.
However, I'm confident that importing the now clean Git repository into Mercurial is much simpler than the original attempt of importing the Subversion repository into Mercurial, so the door to Mercurial is still open.
The next steps
After all of the above, I was ready to ponder the concrete next steps that must be undertaken to actually migrate the Cafu Engine to Git.
But as this matter in all its details is very complicated and involved, I finish this post at the overview level.
In my next post, I'll provide more details on the requirements and goals of the conversion, and why it was so difficult to implement. Things will get more technical (and practical) then, and I'm going to provide the exact steps on how the conversion was eventually implemented. As the bug and issue tracker is closely integrated with Subversion, we'll have to have a look at it, too.
Please let me know what you think, I'm looking forward to your feedback!
However, over the years, the requirements of developers and users have evolved, as has the Cafu Engine and available version control systems. Increased flexibility and ease of work for everyone who participates in the Cafu Engine are more important than ever.
With DVCS – distributed version control systems – being widely spread and well known today, most prominently Mercurial and Git, and with related hosting and collaboration platforms such as Bitbucket and Github readily available to everyone, it's time for change.
In this post I will summarize the current state of affairs regarding the migration of Cafu to Mercurial or Git.
Why DVCS?
Why should we migrate from Subversion to Mercurial or Git at all?
What are the goals?
- First and foremost: Our users use the Cafu source code
to develop their own games and applications, but would also like
to integrate the latest enhancements and bug-fixes from the official Cafu
code base. Keeping up-to-date by applying the latest changes of Cafu into
your own code base can be cumbersome with Subversion, but is easy to do
with Mercurial or Git.
- Similary, developing with and contributing to Cafu
should be easy. Anyone who wants to contribute an enhancement, a bug-fix or
a new feature should be able to do so in the simplest manner possible.
This will later be described in greater detail in the wiki, but in brief, the primary method would be to create a pull request at Bitbucket. Fallbacks and alternatives would be posting pull requests at the issue tracker or the mailing-list, or to submit patches by uploading them to the issue tracker or sending them to the mailing-list.
- Better branching than Subversion. Branching is a vital
tool to us even with Subversion.
- We use a special flavor called "vendor branches" to manage our
external libraries.
- In our website, we use vendor branches as well, for separating
"live" from "pristine" content.
- Last but not least, the use of branches in Cafu as "feature
branches" was existent, but underutilized. Employing a more
sophisticated branching model like the one described here
will only be possible with Mercurial or Git.
- We use a special flavor called "vendor branches" to manage our
external libraries.
- Implicitly contained backups. As everyone always has a
full copy of everything, the worries about creating backups for the
repository are virtually eliminated. This is important for our actively
used Cafu source code and website repositories, but also for legacy
repositories that we no longer use, but still keep around.
- Repositories that are no longer in use and have been archived require no special measures to inspect, use or even revive them at any later time. No server is necessary to do research and archeology even in long archived repositories.
Mercurial or Git?
The internet is full of related debates already. As I do not want to start another one, I'll be brief:
In my opinion, Mercurial is easy to learn, well documented, and powerful enough for 99% of all use cases and users. For new projects with no pre-existing history, Mercurial is my clear favorite.
Git is technically more sophisticated, but comes with a horrible command-line interface. These days it is easier to learn than it used to be, but developing a proper mental model and becoming a confident (admin) user still takes a very big effort.
A fair and competent opinion about Mercurial and Git was expressed by Sinbad, the founder and former lead of the Orge3D project. I much agree with his points in this discussion. (Continue reading on the subsequent pages 13 and 14, where he also links to his detailed review and comparison.)
Besides studying all the existing, prevalent sources, during the last few weeks and months I also spent huge amounts of time with evaluating both Mercurial and Git myself: The minimum that I wanted to accomplish was gaining a good understanding of each system, import the existing Cafu Subversion repository, and run some real-live tests that resemble daily routine Cafu development.
My opinion about Git:
- Regarding the negative aspects, I have to agree with Steve Bennett's blog post "Ten things I hate about Git". And he forgot to mention that Git under Windows only exists due to a small group of volunteers who are not involved in Git core development.
- BUT: Git is widely supported by web hosters. All hosters that I have a contract with (LCube and 1und1) now support Git without any further ado (none of them supports Mercurial).
- AND: Git has with
git-svna very good interface to Subversion for both parallel use or one-time conversion.
Despite my original preference for Mercurial, I must say that I spent more time with Git (maybe because it took me three printed books to get a good understanding of it), so probably in the end I was more biased than I now like to admit.
As we will see later, the initial importing of the Subversion repository turned out to be the crux. After a long battle, it turned out that I was able to complete the conversion to Git in exactly the clean, complete and careful way that I wanted, whereas my attempts at converting to Mercurial were unfortunately much less fruitful. Things had probably gone better for Mercurial if I had invested more time into it, but then I have still no idea how I could have done with Mercurial what I did with Git.
With this experience, I eventually chose Git to proceed with the next steps.
However, I'm confident that importing the now clean Git repository into Mercurial is much simpler than the original attempt of importing the Subversion repository into Mercurial, so the door to Mercurial is still open.
The next steps
After all of the above, I was ready to ponder the concrete next steps that must be undertaken to actually migrate the Cafu Engine to Git.
But as this matter in all its details is very complicated and involved, I finish this post at the overview level.
In my next post, I'll provide more details on the requirements and goals of the conversion, and why it was so difficult to implement. Things will get more technical (and practical) then, and I'm going to provide the exact steps on how the conversion was eventually implemented. As the bug and issue tracker is closely integrated with Subversion, we'll have to have a look at it, too.
Please let me know what you think, I'm looking forward to your feedback!