I've been wondering lately whether or not I should be moving my different projects from subversion to mercurial. Not so much because subversion could have let me down in any ways, I've been very happy with it, but rather because I wonder if it would help users of said projects to experiment and become occasional or regular contributors.
If anything, the distributed model lower the barrier for users to branch and go wild with ideas they might have. I don't really want to add contributors to my subversion repository just so that they can try something out that might not have any happy outcome. I've been happy enough that my projects had never drawn more attention that I could handle but that doesn't mean I don't want people to take over in some fashion and I've been wondering if DCVS like mercurial wouldn't allow that. Ultimately of course the official repository would be the one available on defuze but it would still be much easier for people to try out and propose modifications or extensions to projects.
Anyway, I would be happy in your feedback on the subject as I'm still trying to make my mind around this issue.
I've been using Mercurial quite a bit recently. I like how lightweight DRCSs are in general. I don't know if additional buy-in from others might be hampered by the relative "fringe" nature of DRCSs though.
FWIW, we're considering moving to Mercurial at work too. We're going to try some new development practices that fit well with a DRCS.
We've found this to be very cool with the Gnome Do project. By having the code in bzr people come in and say "Hey, how can I do XX or add YY" and we just tell them to make a branch and have at it. If we like it, it'll get merged in.
I see the same thing possible with mercurial. The only big thing is that with bzr in launchpad, you can see a list of people that made branches, while in Mercurial, people can branch/hack o nthings, but you might not realize they're out there unless they bring it back to your attention.
If so, I would be interested in a short review about how well DVCS-Plugins for Trac work. I've used the Git plugin some time ago and it was not very mature.
Indeed I would keep Trac. A system that would not allow it would be a no-go for me at the present time unless I could replace it with something as good.
I use git on the client side as my version control system even with servers that use Subversion, thanks to git-svn. It lets me develop my patch while tracking the trunk and easily merging the changes onto my local branch. Then when the branch is ready, I can generate a diff against the current trunk and mail it to the maintainer. On Subversion servers where I have an account, I can use git-svn dcommit to push my changes back up to the server, either as separate commits or just 1 commit.
So, this is just to say that running a Subversion server is no longer an obstacle to other people doing DVCS-style development. It only make sense to switch the server if the primary maintainers would benefit.
Never mind the other users. Try out mercurial. For most of my projects, I am the only contributor--I still use it and still find it extremely valuable. Want to try out something very experimental without messing up your working code base? Just clone a new directory and put your experiment in there. If it works out, you merge it back and you're done. If it doesn't, you can toss the directory, or archive it somewhere--it still has value, and all the commits you made into it can still be merged in later if you want. And all the while, you can still be putting bug fixes into your non-experimental repos.
The ability to make commits to experimental code without wincing about doing damage to your revision history is worth the switch, alone.
FWIW, we're considering moving to Mercurial at work too. We're going to try some new development practices that fit well with a DRCS.
Friday, May 2. 2008 at 10:50 (Link) (Reply)
I see the same thing possible with mercurial. The only big thing is that with bzr in launchpad, you can see a list of people that made branches, while in Mercurial, people can branch/hack o nthings, but you might not realize they're out there unless they bring it back to your attention.
Friday, May 2. 2008 at 11:32 (Link) (Reply)
Friday, May 2. 2008 at 11:39 (Reply)
If so, I would be interested in a short review about how well DVCS-Plugins for Trac work. I've used the Git plugin some time ago and it was not very mature.
Friday, May 2. 2008 at 12:02 (Link) (Reply)
Friday, May 2. 2008 at 12:06 (Reply)
If you're ever fed up with trac (as I was) then give redmine (http://www.redmine.org) a shot.
It beats trac hands down in every regard. Most importantly the ticket-system is very usable (very much unlike trac).
Disclaimer: I'm not affiliated with redmine in any way, just a happy user spreading the word because I'm so tired of all those crappy trac sites...
Monday, May 5. 2008 at 08:02 (Reply)
Monday, May 5. 2008 at 15:34 (Reply)
So, this is just to say that running a Subversion server is no longer an obstacle to other people doing DVCS-style development. It only make sense to switch the server if the primary maintainers would benefit.
Friday, May 2. 2008 at 12:50 (Reply)
The ability to make commits to experimental code without wincing about doing damage to your revision history is worth the switch, alone.
Friday, May 2. 2008 at 13:10 (Link) (Reply)