Re: VCS comparison table

Aaron Bentley wrote:

Linus Torvalds wrote:

quoted

If you want a short, human-readable name, you _tag_ it. It takes all of a
hundredth of a second to to or so.

But tags have local meaning only, unless someone has access to your
repository, right?

Tags are propagated during clone, and during fetch/pull (getting changes
from repository). So in that sense they are global.

If you don't publish your repository, then neither tags, nor <URL>+<rev no>
has any sense, any meaning to somebody other than local private repository.
 

quoted

Well, in the git world, it's really just one shared repository that has
separate branch-namespaces, and separate working trees (aka "checkouts").
So yes, it probably matches what bazaar would call a checkout.

The key thing about a checkout is that it's stored in a different
location from its repository.  This provides a few benefits:

- you can publish a repository without publishing its working tree,
  possibly using standard mirroring tools like rsync.

git clone --bare
 

- you can have working trees on local systems while having the
  repository on a remote system.  This makes it easy to work on one
  logical branch from multiple locations, without getting out of sync.

In git we usually use "git clone --local" (with repository database
hardlinked) or "git clone --shared"/"git clone --reference <repository>"
(which automatically sets alternates, i.e. file pointing to alternate
repository database) for that. This way one gets his/her own refs
namespace, so two people can work on different branches simultaneously.

Alternate solution would be to symlink .git, or .git/objects (i.e.
repository "database").

- 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).

In git you can access contents _without_ checkout/working area.
For example gitweb (one of git's web interfaces) uses only repository
database and doesn't need checkout/working area.

quoted

Almost nobody seems to actually use it that way in git - it's mostly more
efficient to just have five different branches in the same working tree,
and switch between them. When you switch between branches in git, git only
rewrites the part of your working tree that actually changed, so switching
is extremely efficient even with a large repo.

You can operate that way in bzr too, but I find it nicer to have one
checkout for each active branch, plus a checkout of bzr.dev.  Our switch
command also rewrites only the changed part of the working tree.

Luben (IIRC) works this way.