I currently use Subversion for my one-person software company. Is it worthwhile moving to Hg (Mercurial)? Or are the benefits only realisable with a multiperson team?
views:
232answers:
7
+3
A:
I would strongly recommend you reading hginit. It is a great tutorial for Hg and there's a chance that after reading it you will be sold :-)
Darin Dimitrov
2010-03-15 10:56:40
there's a chance that the first subversion bashing chapter should be read with a grain of salt. i've been there, seen that - three developers trying to reintegrate a branch for a whole week. but it was our fault and hg couldn't have merged it back either. one ought to learn how to use release- and bugfix-branches correctly (also with hg btw!) and then svn just works (almost) as well as hg.
stmax
2010-03-15 11:37:48
While hginit was one of the best tutorials out there, it actually did quite a bit to convince me that mercurial is not a good replacement for SVN at our company.
msemack
2010-03-15 16:32:34
i think one thing hginit is missing is "hg branch". it explains tags and "branching by cloning", but it doesn't explain how to create branches within the repo with "hg branch". maybe i'm missing something, but when i run hg on a server, i cannot (or don't want to) have to create a server-side clone and configure permissions every time someone wants to create a feature branch. creating branches inside the repo with "hg branch" seems to be the only plausible solution with hg.. yet hginit doesn't say anything about it.
stmax
2010-03-15 23:19:15
+2
A:
one advantage is that you could work offline, like when you're coding at the customer without a connection to your source control server. how often do you do that?
otherwise i'd just stick with subversion. if you need them, learn how to correctly use release- and feature-branches. there's no reason to move to hg for that, even if hginit tells you how bad subversion is ;)
stmax
2010-03-15 11:32:00
Drawbacks to Mercurial: (1) No svn:externals, (2) You need to keep an entire copy of the repository locally - This sucks if you like to keep several projects in one big repository. This problem is compounded by point #1, which means it is hard to share code between projects.
msemack
2010-03-15 16:35:56
#1 was one of the reasons why we decided not to use hg at work. i have a subversion server running with about 50 users and about the same number of repos.. svn:externals are everywhere.
stmax
2010-03-15 23:14:36
@msemack: your number (2) is actually precisely one of the biggest advantage of a DVCS and is precisely the reason why it's a DVCS and not just a VCS. Last time I checked uber-projects like Linux, OpenJDK, Python, OpenSolaris, Xorg etc. where all using DVCS and most *loved the switch*. If a team of 50 developers has an overreliance on unrelated projects then it may be time to wonder why DVCSes work the biggest projects on this planet and why it doesn't work for a small team of 50.
Webinator
2010-03-16 20:25:25
@WizardOfOdds You haven't refuted point #2. All of your examples are single projects that are a lone "island". Our company literally has 100's of projects, with a decent amount of sharing between them. All of these projects live in one repo. They are organized in hierarchical trees. Adding a new project is an 'svn mkdir http://sever'. Can't do that with Mercurial.
msemack
2010-03-17 19:41:59
The other drawback to a DVCS (which I didn't bring up originally) is that it encourages frequent commits, but only to your local repo. That means all your work is still on your laptop's hard drive, not on the server's RAID array with tape backups. Guess what happens when your hard drive crashes, or your laptop is stolen? To me, the biggest advantage to a version control system is that it gets the master copy of the code off of the local machine and puts it in safe place.
msemack
2010-03-17 19:46:24
@msemack - To be honest, these are only problems with the specific workflow in use, there are other ways ways to design a workflow which don't depend on the monolithic repository. Split up your project into a suitable set of repositories and the need for externals can probably be removed entirely. As subrepos mature this will get easier and there has already been some discussion of partial clone support in Mercurial.
Mark Booth
2010-03-29 19:54:07
The problem is that as the number of repositories grows, the management overhead grows. Oh, one other problem: Forget about using binary files and file locking with a DVCS. This REALLY sucks if you want to version any kind of Excel Files, CAD Drawings, etc.
msemack
2010-03-30 12:51:42
+4
A:
Almost anything is better than using Subversion IMO. I like Mercurial (hg) and Darcs, but my favourite by far remains Fossil for personal projects (as well as shared). With one binary and one file per repository it's easy to keep track of my work, easy to back it up, easy to move it around, etc. Further, the built-in wiki allows me to keep my brainstorming together with my sources, the ability to check in my documentation (generated or otherwise) and access it through the built-in server puts all my work in one place and the built-in issues tracker lets me keep a running history of what I've worked on or need to work on in the future.
Oh, and Windows isn't quite as much a second-class citizen with Fossil as it is with a few other DSCMs I can name. (I'm looking at you here, Git.)
JUST MY correct OPINION
2010-03-15 11:41:08
Your question asks "distributed source control *LIKE* Mercurial". I suggest rewording your question if you want only Mercurial.
JUST MY correct OPINION
2010-03-16 00:37:27
+8
A:
I think it's worthwhile, even for a single person -- but I'm sort of biased since I'm a Mercurial developer :-) Even if you never branch and merge, Mercurial is a better Subversion for the basic operations like commit and tag:
hg commit: very fast so you'll tend to make more fine-grained commits than with Subversion. A commit is also truly atomic in Mercurial since we have no mixed revisions. I count that as an advantage, but people may obviously disagree here.hg tag: points to a specific point in the history, not a copy under/tags. The problem with Subversion tags is that the copy may or may not be identical to how/trunklooked at a specific revision. Subversion really has no built in tags, and while emulating them, it's possible to mess up in ways that you cannot do in Mercurial.
Because Mercurial is so fast, people are using it in different ways than you would use Subversion. A good example of this is hg bisect. You use it to find the first revision where a particular error is present. It works by binary search, where you halve the search interval in each step. You could definitely do this with Subversion too, but there are no built in support for it and it would be slower because you need to contact a server over the network.
The record extension is another really nice feature of Mercurial. It lets you commit only some of the modifications inside a file. This is nice since it lets you make small and self-contained commits.
Martin Geisler
2010-03-15 13:33:23
+3
A:
Yes it is. Despite the 'distributed' designation of mercurial, I would argue its especially good for a lone developer. You get similar features to SVN(plus a lot of other ones) but in general they work better and faster. Setup, backup and maintainence of the repository is much easier. It was designed to allow many lone developers to work together so many features are useful before you need to work with someone else.
My favourite advantages are simple copy-paste backup, and the ability to clone the repository for an instant 'sandbox' environment. I'm a bit scatter brained so its nice to be able to spawn a new environment, try out an idea and decide if I want to integrate it into the main codebase. I can do this without disturbing the original task I was working on.
When I first switched to hg, it was a constant feeling of 'oh..that works a lot better then svn'. At this point I would not consider SVN for myself or with a small team and would only consider Mercurial, Git or similar DVCS.(I do prefer mercurial though)
mfperzel
2010-03-15 18:35:50
+5
A:
From my experience , Git and Mercurial are currently more suitable for open source project or small team or single person team. So, in your case, I would recommand them. Subversion is more suitable for big organizations that need centralized repo and more fine-grained access control.
bo
2010-03-16 04:33:09
A:
I'd recommend definitely using revision control for solo development. It doesn't matter too much which you use, SVN, Git, Hg, etc. The reason why is that it allows you to rollback in the event of regressive bug, loss of code, corruption, and of course branching and merging capabilities (you should always develop in a branch and only merge with trunk when the new feature/bug is full tested), etc. All these things (and more) you won't be able to leverage without a version control system.
Mark Bathie
2010-03-23 21:16:15