[Noisebridge-discuss] big led screen

Andy Isaacson adi at hexapodia.org
Thu Feb 26 21:34:03 UTC 2009


On Thu, Feb 26, 2009 at 01:16:18PM -0800, Mitch Altman wrote:
> For those of us who aren't familiar with it, could you say a little
> bit more about what Mercirial is?  And how to use it?  Is there a wiki
> page on our site about it?

Mercurial is a Distributed Version Control System (DVCS) similar in
usage model to Git, the system used to manage the Linux kernel.  (See
[1] below for why I recommend Mercurial over Git.)

I recommend DVCS for all new software projects, rather than centralized
VCS systems like Subversion (SVN) or ancient, crufty systems like CVS or
(shudder) SourceSafe.  There is a small additional cost to using DVCS in
some cases -- you have to think about local versus remote repositories
-- but the benefits are enormous.  (See [2] below for one caveat.)

The Mercurial wiki at http://www.selenic.com/mercurial/wiki/ has a lot
of great info and introductions for people who've used other systems.

There's an illustrated intro to DVCS Concepts at
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
that provides more details about what all this stuff is.

[1] Why Mercurial?

I prefer Mercurial over Git for small projects because
1. mercurial has a more friendly command line UI
2. mercurial has fewer bizarre failure modes ('what do you mean I have
    to "git reset --hard 689eaf05028f"?')
3. mercurial has a more functional Windows port (although I still
    recommend that Windows users simply run Ubuntu under VMWare Player
    to do real software development rather than attempting to use Cygwin
    or whatever.)
The downside of mercurial, though, is that it's somewhat slower than
git.  Hg commands tend to take up to a second or two rather than git's
blazingly fast UI -- 50 millseconds (yes, I timed it!) for many
commands.  And Hg has a somewhat slower repository engine due to being a
nearly-pure Python implementation rather than Git's insanely complicated
C engine, so really large projects like Linux are not a good fit.


[2] When should you use a centralized VCS rather than a DVCS?

The one caveat to my "always use DVCS" mantra is that projects where
large files are repeatedly modified will explode any DVCS system's
repository size.  So if you're checking in 100MB .avi files (which is
often a stupid idea, but sometimes makes sense, for example video
artists such as our own pvck/mediapathic) and repeatedly modifying them,
then using a centralized VCS may make more sense.  The DVCS systems are
evolving, and there's a reasonable chance someone will come up with a
decent solution to this problem in the next 18 months, but for now,
check your large media files into SVN instead.

-andy



More information about the Noisebridge-discuss mailing list