Re: VCS comparison table

[Jakub Narebski <jnareb@gmail.com>]

Ilpo Nyyssönen wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Ilpo Nyyssönen wrote:
>>
>>> Usability:
>>> 
>>> I have used bzr, bk for development and git very little for following
>>> kernel development. I have followed this discussion quite well.
>>> 
>>> 1. It is easier to start using something you are already familiar
>>> with. (Just try to use Mac OS X with a Windows or Linux background.)
>>> 
>>> G: Something totally new and so no points from here. The way of using
>>> git is just so different from any other similar software.
>>> 
>>> B: Quite clearly gets points from this. Normal branches work quite
>>> like many other software, the checkout stuff works like CVS and SVN.
>>
>> I find for example concept of branches in Git extremly easy to
>> understand.
> 
> Might be, but the point was: Git is harder as it is not like others. 
> In other hand one can see Bazaar like other distributed SCMs and even
> like the not distributed ones as it has the checkout stuff.
> 
> You can give Bazaar for me, a bk user, and I can understand what to do
> with the branches that are like bk clones. (The repository stuff is
> later development and still optional.) Switching a CVS environment to
> Bazaar one can be done so that most of the users can be just told to
> use bzr checkout and they don't have to care about pushing.

That is of course because you are familiar with branch-centric distributed
SCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view
is somewhat limiting; you can always use repository-centric SCM with
one-live-branch-per-repository paradigm and emulate branch-centric SCM,
which is not (or not always) the case for branch-centric SCM. Branch-centric
and repo-centric SCM promote different workflows, namely parallel uncommited
work on few development branches for branch-centric SCM, one-change
per-commit multiple temporary and feature branches for repo-centric SCM.

Breaking from CVS update-then-commit stupid model is IMHO very, very good
idea. On the par of breaking from CVS "model" of branches. In my opinion
CVS had one very good idea (perhaps it wasn't originally CVS idea), namely
using merge instead of locking files for editing; well that and the fact
that it tried (emphasisis on tried) to treat module as a whole, allowing
for multi-file change commits.

Take for example the case of WordProcessors: if they all would only emulate
the UI of leading one (most commonly used), no progress would be made.

> But with git, I clone some repository. Now it is totally new to
> understand that I didn't clone only single branch. It's like nothing
> else and that's what I saw when I first looked at it. I might have
> even not noticed the branch stuff and just cloned it further.

That's the shift of paradigm. Instead of one-branch-per-repository, and
one-branch-per-developer workflow which I think usually stems from that, we
have one-repository-per-developer (usually), and heavily nonlinear
development.

>> On the other side breaking with traditional concepts of _centralized_ SCM
>> in _distributed_ SCM (and geared towards distributed usage) is IMVHO a
>> good idea. And breaking with the cruft of bad ideas of CVS is very good
>> idea. 
> 
> Breaking concepts can be a good idea and I somewhat think that git
> needed to do what it did. But do remember that it came with a cost:
> git is harder to understand and use. You first have to understand that
> it is different and how it is different.

The same could be said about moving from MS-DOS or later MS Windows to the
world of UNIX.

But yes, I understand and agree that being different than others can be
disadvantage... and can be advantage.

>> I don't understand the confusion between "git branch" and "git clone"
>> commands... unless you are confused by Bazaar-NG branch-centric approach
>> which mixes branch with repository.
> 
> Those commands do so different things in different SCMs. Just look at
> the differences bk clone, git clone, git branch and bzr branch. You
> have both. At the point where I didn't yet understand that I cloned
> more than a one branch, git branch is very odd looking command.

I for example didn't understand "bzr branch" concept, being familiar rather
with "git branch".

>> Which long lasting operations lack progress bar/progress reporting?
>> "git clone" and "git fetch"/"git pull" both have progress report
> 
> First note that I didn't notice git repack until recently so things
> got slower until that.
> 
> At least some points they just tell that they are doing something, but
> not how much of it has been done and how much is still to do. Look at
> Bazaar and you'll see the difference, it has progress bars.

Well, having progress bars for operations which are usually fast and one
step is in my opinion stupid idea. Even if there are combinations of
options which makes them slow (for example using so called pickaxe, 
e.g. "git log -S'fragment' -- file" to find revisions which introduced
'fragment' to 'file').

I'll ask again: _which_ git commands you find lacking progress reporting?

>>> You can't just diff branchA/foo branchB/foo.
>>
>> You can: either using "git diff branchA branchB -- foo" which means
> 
> Exactly my point: it forces you to use git more. In Bazaar I can do
> this without Bazaar commands. I could even do it with some Windows GUI
> stuff, take two files or directories and compare.
> 
> As you need to use git commands more than bzr commands, git has bigger
> requirements for usability.

But git commands are more powerfull than equivalent GNU commands. git-diff
is more powerfull than GNU diff (for example it can detect renames and
copying, it shows mode changes, it can show diff for merge using "combined
diff" format), git-grep is more powerfull than GNU grep (for example Linus
finds himself to put files in git repository to use git-grep instead of
combination of GNU find and GNU grep).
 
And don't forget about _cost_ of doing that abovementioned way, namely
having to keep two copies of working area (differing in revision, of
course).

>>> You can't just open file from old branch to check 
>>> something while you are developing in some new branch.
>>
>> You can view file from old branch via "git cat-file -p old-branch:file".

Or you can "git commit -a -m 'TEMP'" to save changes, "git checkout
<branch>" to switch to other branch, perhaps git-clean, hack; hack; hack;
commit changes, swotch back to branch, and wiether amend the commit or reset
index and HEAD (but not working area).

> Same thing here, in Bazaar, I can just open the file from the other
> branch. I can also compile and run the other branch while I have the
> other open.

Do you really often compile and run other branch while developing on other?

> Essentially I would need a separate git repository for each branch
> anyway. In Bazaar I can use the same.

Well, that's a fact that git lacks somewhat (but not lack completly) support
for multiple independent workplaces for the same repository (link+separate
index+separate HEAD), and lacks somewhat (but not completely) support for
sharing object database between repositories aka. bzr model (you have to be
very careful with pruning).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git