On Fri, Mar 14, 2008 at 02:07:29PM +0100, jiho wrote:
On 2008-March-14 , at 13:04 , Aaron Spike wrote:
As you may know a few people are already using DVCS systems to do their work on inkscape. Ted uses SVK (you can tell by the number of times that his commit messages say "SVK screwed up the last commit" :-) ). Mental uses git-svn (he described his use of git-svn for jruby at http://moonbase.rydia.net/mental/blog/programming/using-git-svn-for-jruby) . I've heard that a similar workflow is possible with bzr (http://bazaar-vcs.org/BzrForeignBranches/Subversion ). I have not heard anything of hg but I would expect something similar. We can try these tools now, without switching over the entire repo.
Having said that perhaps there is some worth in switching now.
I know git-svn for using it with all my svn-based repos now. It works nicely indeed. However, I still think the best solution would be to switch completely:
- it would not cost much to each dev (for git at least, skimming over http://git.or.cz/course/svn.html takes 5 minutes, reading it thoroughly takes 30. not a big deal)
- it would avoid a two step process for everyone (svn co first and
then git-svn init if the person wants to do refactoring work on his/ her side)
- the only situation I see where svn is superior is regarding the
integration with online repository browsers and tracking systems such as Trac (there are plugins for git etc. but svn is the default and better supported). But Inkscape do not use such a thing anyway and the online browser of SourceForge is crap enough to be worth replacing by git's web interface. NB: I never used the new interface in Launchpad. I don't know wether it would integrate with git.
I agree this is the right time to talk about switching the repo. Not only to upgrade from SVN, but because SourceForge's SVN service is imperfect (this last month in the middle of our release they expired everyone's SVN passwords with no notice or reason given).
OK, now I think others probably have more informed opinions. Please copy the point by point summary below and add to it.
-- GIT ---------------------------- Good
- very fast (but anything would be faster than svn anyway)
- allows to stash away local changes to fix a small issue. probably
useful when, in the middle of a large code change, one notices a local bug which does not have anything to do with the change (not sure this is git-only)
- 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
(What is TextMate?)
Bad
- Git is designed with the Linux kernel's hierarchical workflow in mind, so may require alteration in how Inkscape's workflow works. - 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')
-- HG ----------------------------- Good
- tortoiseHG
- TextMate bundle
Bad
-- BZR ---------------------------- Good
- already integrated in launchpad
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.h... + 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 Bad by git users)
- supports bundling changesets
- tortoiseBZR
- Fewer commands and built-in help - makes it easier to learn - Supports multiple workflows, including what we use for Inkscape. (See http://bazaar-vcs.org/Workflows) - Many plugins - Easy administration. Mostly done through Launchpad, plus Bzr folks are available to help. - Git uses SHAs for revisions (e.g. 824853772241acf64bc37ac8b85254194741ae13) where bzr uses numbers (e.g., 1, 2, 3.2, 63.3.5.9). bzr has UUIDs internally, but not needed in day-to-day use.
Bad
I happened to be working on two small new projects with other folks in recent months, one under git, the other under bzr, which for me highlighted the benefits of bzr.
For the bzr project, I essentially needed to branch an existing codebase and make some small modifications to it. I located the project on Launchpad, and on the 'code' tab clicked 'Register branch', and it gave me the command to upload my branched code. A few minutes later I was off and running. I hadn't studied any git commands, but just guessed based on my svn experience and everything worked as I expected.
For the git project, the other contributor strongly wanted git, because it was his aim for the code to be adopted by debian. I went through the guidelines for setting up a git repo at debian (took a couple hours to get it all sorted out properly), and let the contributor know. He did not actually know git, so it took him some time to get up to speed, but before long he was sending me diffs to integrate. However, having to wait for me to commit his work created an annoying bottleneck. Perhaps someone with more git know-how would know how to enable multiple committers, but it was not obvious to us git neophytes. Finally, the other contributor switched us over to bzr, and there's been no trouble since.
In both cases, I could take advantage of the distributed form, doing commits for each change individually, and then running a '*** push' when ready to share publically. There wasn't much performance difference with commits between the two, however I did notice git to be faster on pushes, but bzr was definitely fast enough - no more than the time to take a sip of coffee; definitely faster than svn.
There were also a lot of other little differences that made bzr a bit more convienent. For instance, in git if you make changes to several files, you have individually do 'git add' to each in order for them to be included in the commit, or you can do 'git commit -a' which commits all changes. In either case it's different than you'd expect. In bzr, you just do 'bzr commit' and it commits all changes, just like svn.
I've also done merges in git and bzr. With git, the first time I did a merge it was a minor nightmare trying to figure out what options I needed to run. So I was apprehensive the first time I was asked to do a bzr merge. However, it was almost trivially easy.
Bryce