Re: VCS comparison table

[Jakub Narebski <jnareb@gmail.com>]

Aaron Bentley wrote:
> Linus Torvalds wrote:

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

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

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