VCS comparison table

[Sean]

On Tue, 17 Oct 2006 13:19:08 +0200
Matthieu Moy <Matthieu.Moy at imag.fr> wrote:

> 1) a working tree without any history information, pointing to some
>    other location for the history itself (a la svn/CVS/...).
>    (this is "light checkout")

Git can do this from a local repository, it just can't do it from
a remote repo (at least over the git native protocol).  However,
over gitweb you can grab and unpack a tarball from a remote repo.
In practice this is probably enough support for such a feature.

> 2) a bound branch. It's not _very_ different from a normal branch, but
>    mostly "commit" behaves differently:
>    - it commits both on the local and the remote branch (equivalent to
>      "commit" + "push", but in a transactional way).
>    - it refuses to commit if you're out of date with the branch you're
>      bound to.
>    (this is "heavy checkout")

This doesn't sound right, at least in the spirit of git.  Git really
wants to have a local commit which you may or may not push to a
remote repo at a later time.  There is no upside to forcing it all to
happen in one step, and a lot of downsides.  Gits focus is to support
distributed offline development, not requiring a remote repo to be
available at commit time.
 
> In both cases, this has the side effect that you can't commit if the
> "upstream" branch is read-only. That's not fundamental, but handy.

Again this seems really anti-git.  There is no reason for your local
branch to be marked read only just because some upstream branch is
so marked.

> I use it for example to have several "checkouts" of the same branch on
> different machines. When I commit, bzr tells me "hey, boss, you're out
> of date, why don't you update first" if I'm out of date. And if commit
> succeeds, I'm sure it is already commited to the main branch. I'm sure
> I won't pollute my history with merges which would only be the result
> of forgetting to update.

This is exactly the same in Git.  You really only ever push upstream
when your local changes fast forward the remote, (ie. you're up to date).
Git will warn you if your changes don't fast forward the remote.
 
> The more fundamental thing I suppose is that it allows people to work
> in a centralized way (checkout/commit/update/...), and Bazaar was
> designed to allow several different workflows, including the
> centralized one.

While Git really isn't meant to work in a centralized way there's nothing
preventing such a work flow.  It just requires the use of some surrounding
infrastructure.

Sean