OT local version control?

Hi, all,

This isn’t about rspec, but this list has people whose opinions I
respect.

So, I’m looking for a new version control system for my local
development. I
was going to install subversion, but I’ve heard rumors of people using
some
newer ones. Thoughts? I’d like to be able to run it either locally or on
a
home server. If I run it off a home server, then it needs to support
offline
access, so that I can use a cached version when I’m not on my home
network.
For simplicity’s sake, running it locally is probably a better solution.

What do you all use?

-Corey

On Jan 27, 2008 3:33 PM, Corey H. [email protected] wrote:

What do you all use?

I use mercurial and git. I really like them both for different
reasons. I’d recommend you play with both for a minute and see which
one appeals to you.

They’re both distributed scm, which means what you have locally is a
complete repository from which you can checkout, branch, merge, etc.
Then you can pull and push changesets (in hg-speak) or commits (in
git-speak) from and to other repos.

Either way - dscm is a completely different experience from working w/
a remote svn repo. I’m quite certain you’ll enjoy exploring it.

Cheers,
David

I can see this descending into a mercurial vs git religious war :slight_smile:

Hi Corey. I’m using mercurial for both home and work use (supplementing
some
of subversion’s shortcomings, mainly around merging). I looked (briefly)
at
git and - less briefly - at darcs. I settled on mercurial for purely
non-scientific reasons. People whose opinions I respect are using it,
the
community seems both accommodating and active, and it’s python which
means
it runs anywhere python lives, which is all of my home and work
environments.

Others on this list - including the lovely David - are using git and
having
just as much fun and productivity, so I’m sure it comes down to a matter
of
taste in the end.

The big shift, though, is from centralised to distributed source
control.
This means that any working copy is also a full repository in its own
right,
so you can do everything you would usually need the server for:
branching,
tagging, cloning, logging, checking in, rolling back, etc. This page (
http://tinyurl.com/ykcs25) from the Mercurial wiki gives a pretty good
overview. The basic model will be the same for any of the distributed
SCMs.

My experience so far is:

git: insanely fast, made up of many shell scripts, big command set, does
/BIG/ repositories (currently used for the entire linux kernel), doesn’t
run
on windows.
darcs: also fast, written in haskell so less “hackable”. Has best
cherry-picking support (choosing out-of-sequence changesets). Apparently
doesn’t do so well under biiig repositories.
mercurial: also fast (seeing a pattern here?). Seems to scale well. Has
(deliberately) svn/cvs-like command set where it can, so easy to adopt.
This
is where I’ve ended up.
monotone: the first distributed scm I came across (Dave A. was using
it
before any of the rest of us had heard of distributed scm). Never really
used it much.

At the end of the day it will be a personal preference. But whichever
you
end up with, my prediction is that you’ll enjoy it much more than
subversion.

Cheers,
Dan

On Jan 27, 2008 2:00 PM, Dan N. [email protected] wrote:

I can see this descending into a mercurial vs git religious war :slight_smile:

Doubtful. The enlightened among us don’t have time to bother with
mouthy users of that inferior dvcs.

A good thing to note is that you can run many of the distributed scm
tools
in a ‘svn wrapper’ mode to ease transition with existing repositories.
That
made the switch much easier for me.

  • Chad

although i primarily use mercurial, bazaar (http://bazaar-vcs.org/) is
also worth a mention

We recently started using git on our project. It still uses a svn
repository and we enjoy the use of the git-svn bridge to synchronize
things. There are a few things we haven’t figured out how to do yet
with git-svn:

  • create tags or branches
  • commit to tags or branches
  • see the filenames of files that changed in a particular commit

We are very happy with git, and git-svn is making the transition to
git itself much easier. In the past I tried darcs on a few personal
projects and I was happy with it, but the git-svn bridge won me over
when transitioning projects that already used svn.

Zach

Thanks to everyone for their comments, as well as the lack of SCM
fighting.
:slight_smile: Being on vista, it appears that my choices are a bit limited.

-Corey

Yes, bazaar deserves extra props because it’s the scm powering a lot of
the
Ubuntu integration projects. It’s open source (I think they pretty much
all
are) but its development is sponsored by Canonical, which is the company
behind Ubuntu.

I can’t remember why I ditched bazaar - I think it was because it didn’t
have an eclipse plugin, but I’ve since discovered that really doesn’t
matter
with a decent scm.

On Feb 3, 2008 3:13 PM, Corey H. [email protected] wrote:

Thanks to everyone for their comments, as well as the lack of SCM fighting.
:slight_smile: Being on vista, it appears that my choices are a bit limited.

I don’t know about Vista, but being using bzr (http://bazaar-vcs.org/)
for 8 months and the shift from tradition centralized repositories
(svn, cvs) to distributed was a joy.

It also doesn’t hide you under the same checkout all your branches (to
avoid costly disk space?)

Anyway, not starting the fight… not now, but I leave you with a link
comparing Bzr to Git [1] and Bzr to Hg (Mercurial) [2]

On a side note, I’ll like to point that it allow you push branches to
websites using just dumb protocols like ftp and http for retrieving,
with is something sueful for someone with lack ssh or git server
capability on their hosting providers.

I’m using it to push new development of One-Click Ruby Installer [3]

[1] http://bazaar-vcs.org/BzrVsGit
[2] http://bazaar-vcs.org/BzrVsHg
[3]
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/1e2f1b9a3d611e3b


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

sourcesafe! I’m suggestively working on getting the company I’m at onto
Subversion instead.I feel your pain

I’ll check that out, too, Luis. Thanks!

I’m currently reading up on mercurial, and it is very enlightening. I’ll
admit that, being a .net developer by trade, I’ve not really been privy
to
some of the stuff going on in scm, mostly stuck at a company still using
sourcesafe. Please no comments about how it isn’t really scm. :slight_smile: I’m
definitely getting a mind-opener reading the mercurial site.

My basic need right now is to be able to keep history of my project
(Coupon
Tracker:
http://www.coreyhaines.com/coreysramblings/2008/02/03/TrackingEntertainmentBookSavingsInRailsPartIIIWhyArentYouUsingIt.aspx).
While I’m learning RoR, I want to be able to roll back to a previous
version
if I mess things up too much. :slight_smile: I’m starting to add some AJAX stuff to
the
site, and I want to make sure that I can revert when I misuse it. :slight_smile:

Thanks again to everyone for their input.

-Corey

:slight_smile: We are moving to TFS soon, which will be nice.

-Corey

On Feb 3, 2008 3:45 PM, Corey H. [email protected] wrote:

I’ll check that out, too, Luis. Thanks!

I’m currently reading up on mercurial, and it is very enlightening. I’ll
admit that, being a .net developer by trade, I’ve not really been privy to
some of the stuff going on in scm, mostly stuck at a company still using
sourcesafe. Please no comments about how it isn’t really scm. :slight_smile: I’m
definitely getting a mind-opener reading the mercurial site.

Yes, Mercurial is nice, and have some functionalities similar to git
(topic branches?) which make it more attractive.

In any case, the use of python in both cases make Hg and Bzr a good
alternative to git.

Good luck and hope you then share your findings.
Regards,


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Since it sounds like people don’t mind talking about source control, and
this group has people I trust, I thought, as I went through the
learning/evaluating, I’d ask questions/make statements and get people’s
thoughts. If people on the list get annoyed, though, just let me know
(offgroup is fine), and I’ll stop the distractions, unoffended.

Question/Discussion 1
Coming from an old school source control world, I’m used to the idea of
“check out some files, work on them, check them back in.” It seems like
DVCS
systems, at level 1, is “make a copy of your project, edit the files to
make
the change, then merge it back into your main branch.” I see a lot
discussion with pictures about it really more like a bunch of
copies/branches of one project, moving through time independently, the
merging back at some future date. I’m having a bit of trouble in my mind
with this, so I’ll leave that to the next level.

-Corey

Thanks, Luis!

I’ll do my best to post my findings on my blog.

-Corey

On Feb 4, 2008 9:28 PM, Corey H. [email protected] wrote:

Since it sounds like people don’t mind talking about source control, and
this group has people I trust, I thought, as I went through the
learning/evaluating, I’d ask questions/make statements and get people’s
thoughts. If people on the list get annoyed, though, just let me know
(offgroup is fine), and I’ll stop the distractions, unoffended.

At least this group didn’t react like others with “X is better than
anything else…”

I think David C. personally uses git for rspec, but being a
nice guy, pushes svn mirrors for it.

Question/Discussion 1
Coming from an old school source control world, I’m used to the idea of
“check out some files, work on them, check them back in.” It seems like DVCS
systems, at level 1, is “make a copy of your project, edit the files to make
the change, then merge it back into your main branch.” I see a lot
discussion with pictures about it really more like a bunch of
copies/branches of one project, moving through time independently, the
merging back at some future date. I’m having a bit of trouble in my mind
with this, so I’ll leave that to the next level.

Yeah, can be tricky sometimes, the learning curve can be steep, but is
worth.

When you checkout using a DVCS, you’re not actually getting just a
working copy, but the whole repository history.

In that way, you can get differences, compare, list the log messages,
everything without a single hit to the server (tried do a blame with
svn?)

The idea of branching is that you can implement new features “outside”
trunk and don’t affect the code stability.

I’ve been using Bzr not just for personal projects, but also to track
changes and submit patches to other open source projects, just to
mention:

ruby (1.8 and 1.9)
mongrel
hoe
rubygems
rubyinline
parsetree
rspec (even with the small contribution I did)

Since for most of these projects I don’t have commits rights, and some
of them I don’t even have access to the code (inline, hoe and
parsetree).

I create a “branch” for things, and do small commits based on the
changes I’ve introduced, but that will depend on the workflow you’re
used.

Later, when that feature is ready for integration, you then prepare
and merge upstream with it.

Takes some time to get used to it :wink:

Anyway, at least with bzr, you can work in a similar way to subversion
(running a smart server) and have bound checkout.

In any case, read the documentation of all the dvcs to find the one
that fits your current workflow but will allow improve it with time.

HTH,

Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Hi Corey.

I recently discovered a rather excellent online book:
http://hgbook.red-bean.com/

It’s about mercurial but it’s a) largely scm-agnostic and b) really well
written, with some useful diagrams about how changesets work in the
small
and collaboration models in the large (i.e. exactly what you were asking
about).

I also discovered a “deal-breaker” feature of mercurial that I hadn’t
realised before, which is that it tracks changes across copies and
renames
of files. Or rather, what I hadn’t realised is that other SCMs don’t do
this. This was what was crippling me with subversion - I had a branch
where
I had done some quite aggressive refactoring (which means files getting
moved and/or renamed), and subversion wouldn’t merge the changes from
the
branch onto trunk.

Thanks for the response, Luis.

I’m going through the user manual, and it looks like I can set up a main
branch, make a clone, work on the clone with its own
repository/revisions,
then merge the changes back to the main branch when I’m ready. I like
the
idea of being able to work on several things at once. I’ll let you guys
know
how it goes.

-Corey

Thanks, Dan, I’ll check that out.

-Corey