VCS comparison table

[Matthieu Moy]

Sean <seanlkml at sympatico.ca> writes:

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

Anyway, given the price of disk space today, this only makes sense if
you have a fast access to the repository (otherwise, you consider your
local repository as a cache, and you're ready to pay the disk space
price to save your bandwidth). In this case, it's often in your
filesystem (local or NFS).

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

I lied in my above description ;-).

I should have said "by default" ... but you have "commit --local" if
you want to have a local commit on a bound branch (at this point, I
should remind that not all branches are "bound branches". "bzr branch"
creates branches similar to git ones).

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

Will, take the example of my bzr setup.

I have one repository, say, $repo.

In it, I have one branch "$repo/bzr.dev" which is an exact mirror of
http://bazaar-vcs.org's branch.

I also have branches for patches (occasional in my case) that I'll
send to upstream. Say $repo/feature1, $repo/feature2, ...

If, by mistake, I start hacking on bzr.dev itself, I'll be warned at
commit time, create a branch, and commit in this new branch. I believe
git manages this in a different way, allowing you to commit in this
branch, and creating the branch next time you pull. But you know this
better than I ;-), I never got time to give a real try to git.

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

Yes, but you will have to do a merge at some point, right ? While I'm
keeping a purely linear history (not that it is good in the general
case, but for "projects" on which I'm the only developper, I find it
good. For example, my ${HOME}/etc/).

But don't get me wrong, I also prefer the decentralized way in most
case. And I'm happy that bzr and git work like this by default. Just
that at least *I* have cases where a centralized approach suits me
better, and then I'm happy with that particular feature of bzr.

-- 
Matthieu