VCS comparison table

[Erik Bågfors]

> > - - you can use a checkout to maintain a local mirror of a read-only
> >   branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).
>
> I'm not sure what you mean here.  A bzr checkout doesn't have any history
> does it?  So it's not a mirror of a branch, but just a checkout of the
> branch head?

In bzr there are two different kind of checkouts.  One is a called a
lightweight checkout and that's really a "normal" checkout in the way
svn for example does it.  In this mode, you have the branch remotely
and only the working tree locally.  So it's just a checkout of the
branch head (of any other revision if using -r when doing the
checkout).

Then there are none lightweight checkouts, heavyweight checkouts.
These are the default type.  A heavyweight checkout is in fact a full
branch locally, but it is "bound" to the remote branch.  What this
means is that all commands such as diff/status/log/etc can be done
locally. So it's really quick.

It acts the same as a lightweight checkout in most regards, so when I
run "bzr update" it actually pulls from the remove branch, and when I
run "bzr commit" it commits the same revision in both the remote
branch and the local branch. It does this in one transaction so one
can't work and the other fail (they would both fail in that case).

What this also gives you is that when you want to clone the branch,
you don't need to go the the remote branch to get the revisions and
also, when being offline, you can commit locally.

Committing locally is a very cool feature in my mind.  If you work in
a centralized manner with checkouts, you normally commit directly to
the central branch, but when you are offline, that will fail (of
course :) ).  So what you can do then is to run "bzr commit --local"
to commit only to your local checkout branch, then when you get online
again you can run "bzr update".  In this case the update will take any
new commits that has been done while you were away, pull them into
your local branch, and make your local commits into something that has
been merged into the "checkout".

I find this REALLY useful.

Don't know if that made sense, here it is in commands.

$ bzr checkout t p
$ cd p
$ echo hej >> hosts
$ bzr commit --local -m 'offline'
$ echo hej >> hosts
$ bzr commit --local -m 'offline 2'

Now I get back, someone has committed new stuff... I run bzr update
$ bzr update
All changes applied successfully.
Updated to revision 2.
Your local commits will now show as pending merges with 'bzr status',
and can be committed with 'bzr commit'.
$ bzr status
modified:
  hosts
pending merges:
  Erik Bågfors 2006-10-20 offline 2
    Erik Bågfors 2006-10-20 offline
$ bzr commit -m 'my offline stuff'
modified hosts
Committed revision 3.

$ bzr log -r-1
------------------------------------------------------------
revno: 3
committer: Erik Bågfors <erik at bagfors.nu>
branch nick: p
timestamp: Fri 2006-10-20 10:51:08 +0200
message:
  my offline stuff
    ------------------------------------------------------------
    merged: erik at bagfors.nu-20061020084949-8bc43db8f5cd449b
    committer: Erik Bågfors <erik at bagfors.nu>
    branch nick: p
    timestamp: Fri 2006-10-20 10:49:49 +0200
    message:
      offline 2
    ------------------------------------------------------------
    merged: erik at bagfors.nu-20061020084945-13e5093f98c0c380
    committer: Erik Bågfors <erik at bagfors.nu>
    branch nick: p
    timestamp: Fri 2006-10-20 10:49:45 +0200
    message:
      offline

I think that bzr really allows you to work well in a centralized
environment as well as a distrubuted, which is one of the things I
like best about bzr.

Regards,
Erik
-- 
google talk/jabber. zindar at gmail.com
SIP-phones: sip:erik_bagfors at gizmoproject.com
sip:17476714687 at proxy01.sipphone.com