Re: VCS comparison table

Jakub Narebski [off-list ref] wrote:

[...]

I'd rather split "Supports Renames" into engine part (does SCM
remember/detect that rename took place _as_ rename, not remember/detect it
as copiying+deletion; something other than rename) and user interface part:
can user easily deal with renames (this includes merging and viewing file
history).

I think that what to tool does in its guts is completely irrelevant, what
is important is what the user sees. Sadly, it seems hard to describe
exactly what is meant/wanted here.

[...]

7. Checkouts (as a noun). This probably read "Support Centralized and
Disconnected Centralized Workflow" but that is perhaps too wordy. Git would
have "No" for "Centralized"

Why? We could all agree that some repository is "central" and all push/pull
there. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,
but...

[...]

13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
or "?" background color for Git. And add note that it is easy to script up
porcelanish command, and to add another merge strategy. There also was
example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
marking.

Mostly an implementation detail for "extensible"...

[...]

19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

Ilpo Nyyssönen wrote:

Jakub Narebski [off-list ref] writes:

quoted

Ilpo Nyyssönen wrote:

quoted

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.

quoted

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.

quoted

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

quoted

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?

quoted

quoted

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

quoted

quoted

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

On Fri, Oct 27, 2006 at 11:34:09AM +0200, Andreas Ericsson wrote:

Horst H. von Brand wrote:

quoted

Jakub Narebski [off-list ref] wrote:

quoted

19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

This one just needs to go.

It's certainly a hard question to answer, and will never be answered
completely, but unfortunately it's also a really *important* question.
The best SCM in the world isn't much use if I can't convince my
coworkers to learn the thing.

So I think it's helpful to attempt to find out whether we have a problem
here or not, even if the problem is more one of perception than reality.
Though obviously it would be more helpful to have something more
detailed than just a yes or no answer to "is git easy to use?"

Could possibly be replaced with "Has tutorial/documentation online" or
some such. No SCM is really intuitive to users that haven't
experienced any of them before, so the only thing that really matters
is how much documentation one can find online and how up-to-date it
is.

Documentation helps, though sometimes extensive documentation is a sign
of a problem--it takes a lot more documentation to explain how to manage
a branch in CVS than it does in any sensible system....

Dnia niedziela 29. października 2006 00:18, Robin Rosenberg napisał:

lördag 28 oktober 2006 15:53 skrev Jakub Narebski:

quoted

But for example git(7) man page lists git commands clearly divided between
low-level commands (plumbing): manipulation commands, interrogation
commands, synching commands and high level commands (porcelain): main
commands, ancillary commands. The "git help" and "git --help" shows the
most commonly used git commands with short description of each command
("git help -a" show all commands).

I believe people tend to skim through documentation looking for pieces of 
information rather than read it from start to end. So they find themselves 
reading the plumbing documentation first. Simply reordering documentation to 
list the porcelain commands before the plumbing would make the git man page 
less scary to newcomers.

Good idea. Thanks.

Current ordering in git(7) man page is probably the result of bottom-up
git development. First there were plumbing commands (well, first was
repository format AFAICT, but I digress...).

-- 
Jakub Narebski

On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of
Jakub Narebski, and lo! it spake thus:

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.

I don't think that follows at all.

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

Yes.  And I do the same with older revisions along a given branch too,
where is where [lightweight] checkouts come in handy.


-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

Matthew D. Fuller wrote:

On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of
Jakub Narebski, and lo! it spake thus:

quoted

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

Yes.  And I do the same with older revisions along a given branch too,
where is where [lightweight] checkouts come in handy.

Well, if you don't _work_ on other branch, you can alwaych checkout
the other branch or any given revision from a separate directory
using
  git --git-dir=<path to repo> tar-tree <revision> | tar xf -
for example.
-- 
Jakub Narebski

On Mon, 30 Oct 2006, Jakub Narebski wrote:

I was bitten lately by git lack of progress reporting for git-push.
While it nicely reports local progress (generating data) it unfortunately
lacks wget like, "curl -o" like or scp like pack upload progress
reporting. And while usually push is fast, initial push of whole
project to empty repository can be quite slow on low-bandwidth link
(or busy network).

What about this patch?

diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 41e1e74..7f87ae8 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c

@@ -1524,6 +1524,10 @@ int cmd_pack_objects(int argc, const cha
 			progress = 1;
 			continue;
 		}
+		if (!strcmp("--all-progress", arg)) {
+			progress = 2;
+			continue;
+		}
 		if (!strcmp("--incremental", arg)) {
 			incremental = 1;
 			continue;

@@ -1641,7 +1645,7 @@ int cmd_pack_objects(int argc, const cha
 	else {
 		if (nr_result)
 			prepare_pack(window, depth);
-		if (progress && pack_to_stdout) {
+		if (progress == pack_to_stdout) {
 			/* the other end usually displays progress itself */
 			struct itimerval v = {{0,},};
 			setitimer(ITIMER_REAL, &v, NULL);

diff --git a/send-pack.c b/send-pack.c
index 0e90548..9280481 100644
--- a/send-pack.c
+++ b/send-pack.c

@@ -30,6 +30,7 @@ static void exec_pack_objects(void)
 {
 	static const char *args[] = {
 		"pack-objects",
+		"--all-progress",
 		"--stdout",
 		NULL

lördag 28 oktober 2006 15:53 skrev Jakub Narebski:

But for example git(7) man page lists git commands clearly divided between
low-level commands (plumbing): manipulation commands, interrogation
commands, synching commands and high level commands (porcelain): main
commands, ancillary commands. The "git help" and "git --help" shows the
most commonly used git commands with short description of each command
("git help -a" show all commands).

I believe people tend to skim through documentation looking for pieces of 
information rather than read it from start to end. So they find themselves 
reading the plumbing documentation first. Simply reordering documentation to 
list the porcelain commands before the plumbing would make the git man page 
less scary to newcomers.

On 10/27/06, Andreas Ericsson [off-list ref] wrote:

Horst H. von Brand wrote:

quoted

Jakub Narebski [off-list ref] wrote:

[...]

quoted

I'd rather split "Supports Renames" into engine part (does SCM
remember/detect that rename took place _as_ rename, not remember/detect
it as copiying+deletion; something other than rename) and user interface
part: can user easily deal with renames (this includes merging and

viewing file

quoted

quoted

history).

I think that what to tool does in its guts is completely irrelevant, what
is important is what the user sees. Sadly, it seems hard to describe
exactly what is meant/wanted here.

Agreed. I'd rather make the definition "Can users, after a rename has
taken place, follow the history of the file-contents across renames?".
Mainly because this is clearly unambiguous, doesn't involve
implementation details and only weighs what really counts: User-visible
capabilities.

With this definition (with this part) it would be "Somewhat" for Git, because
user can track the history of file-contents across renames, but some additional
steps are required... until --follow=<pathname> would get implemented, that is.
Yet "tracking file-contents across renames" is based on specific workflow used;
for example with Git you usually track [some part of] history of some subpart
of a project, not history of single file. (I'd name it "History Rename Support"
or "Log Rename Support").

But equally important for user is another question related to
"Supporting Renames".
Namely detection of renames during merge and detection of conflict during merge
is what I would consider minimal "Merge Renames Support". Causing information
to be lost is having no "Merge Renames Support". To have "Yes" in this
column SCM
have to resolve conflict at least in obvious cases, and "Yes!" if it
can remember
resolution of merge conflict involving renames ;-).

IMNSHO, I'd rather have all the features in the list be along the lines
of "Can users/admins/random-boon do X?" and instead of "yes/no" list the
number of commands/the amount of time required to achieve the desired
effect. This would set a clear limit and put most terminology issues out
of the way.

This would make the comparison table less clear, unfortunately.

quoted

quoted

13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
or "?" background color for Git. And add note that it is easy to script up
porcelanish command, and to add another merge strategy. There also was
example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
marking.

Mostly an implementation detail for "extensible"...

Yup. Any fast-growing SCM can clearly be said to be "extensible",
otherwise it wouldn't be extended ;-)

I'd put "Easily Extensible" here, and put "Plugins (core+UI)" for Bazaar-NG,
and "Scriptable (UI+merge)" for Git, or something like that.

quoted

[...]

quoted

19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

This one just needs to go. Could possibly be replaced with "Has
tutorial/documentation online" or some such. No SCM is really intuitive
to users that haven't experienced any of them before, so the only thing
that really matters is how much documentation one can find online and
how up-to-date it is.

For example SCM can be easy to use but at the cost of simplifications
and limited useness.

On the other side basic concept behind some SCM might be more
or less understandable...
-- 

Jakub Narebski wrote:

Ilpo Nyyssönen wrote:

quoted

3. Understanding output

G: Speaks a language of its own, hard to understand. No progress
reported for long lasting operations.

B: Could maybe speak a bit more. Progress reporting is quite good.

Which long lasting operations lack progress bar/progress reporting?
"git clone" and "git fetch"/"git pull" both have progress report
for both "smart" git://, git+ssh:// and local protocols, and "dumb"
http://, https://, ftp://, rsync:// protocols. "git rebase" has
progress report. "git am" has progress report.

I was bitten lately by git lack of progress reporting for git-push.
While it nicely reports local progress (generating data) it unfortunately
lacks wget like, "curl -o" like or scp like pack upload progress
reporting. And while usually push is fast, initial push of whole
project to empty repository can be quite slow on low-bandwidth link
(or busy network).

git version 1.4.3.3 on local side, git+ssh:// protocol, git version
1.4.3.3.g9ab2 on the remote side (repo.or.cz).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Sun, Oct 29, 2006 at 01:01:07PM +0100, Jakub Narebski wrote:

quoted

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.

I've got to disagree here.  Being a former bitkeeper user myself, I
find BZR-NG to be nothing like bk.  In particular, Bitkeeper is *not*
branch-centric the way that BZR is; in fact, bk is much closer to git
and bk both in terms of how it works and its terminology.  You can
have a non-linear set of history without using any "branches" in both
bk and mercurial, simply by creating two commits changing different
files in two different repositories (using the bk, git, and hg sense
of the word --- only bzr attaches a completely different definitoin to
term "repository"), and then pull them together.   

With bzr, the only way you can do the following is by explicitly
creating a separate branch and then merging the two branches together.
In bzr --- unlike bk, git, and hg --- when you are on a "branch" the
history must be completely linear.  The difference between bk, and git
and hg, is that bk enforces a restriction that there must be one
"head", or "tip" on a particular repository (in the bk, hg, and git
sense).  So if you start by cloning the repository A -> B, and then
make one or more commits in repository A, and then one or more commits
in repository B, when you pull from repository B to A, bk will enforce
the creation of a merge changeset on the resulting repository --- or
fail the merge.  (Actually, with BK there was the option to create
multiple tips using "lines of development", but it was never fully
developed or supported.)

With hg and git, you have the *option* of pulling the two lines of
commits together using a merge changeset *or* leaving the two "tips"
or "heads" unmerged.  But that's only a very minor difference between
bk and hg/git --- and if you are willing to always merge two heads
after pulling so that your git or hg repository only has one head/tip,
then conceptually the changeset history is just like bk.

In contrast, it's impossible to do this with bzr without leaving the
named branches around, so in this sense it's quite different form BK.

						- Ted

P.S.  I'm going to teaching a class entitled "Bzr, Hg, and Git, Oh
my!" at LISA conference in Washington, D.C.  It's only a half-day
tutorial intending to cover the basics of Distributed SCM systems, so
most folks on this list will probably know everything I'm planning on
discussing, but if you have some colleagues who need a gentle
introduction, please feel tell them to head on over to the LISA
conference website at www.usenix.org.

Horst H. von Brand wrote:

Jakub Narebski [off-list ref] wrote:

[...]

quoted

I'd rather split "Supports Renames" into engine part (does SCM
remember/detect that rename took place _as_ rename, not remember/detect it
as copiying+deletion; something other than rename) and user interface part:
can user easily deal with renames (this includes merging and viewing file
history).

I think that what to tool does in its guts is completely irrelevant, what
is important is what the user sees. Sadly, it seems hard to describe
exactly what is meant/wanted here.

Agreed. I'd rather make the definition "Can users, after a rename has 
taken place, follow the history of the file-contents across renames?". 
Mainly because this is clearly unambiguous, doesn't involve 
implementation details and only weighs what really counts: User-visible 
capabilities.

IMNSHO, I'd rather have all the features in the list be along the lines 
of "Can users/admins/random-boon do X?" and instead of "yes/no" list the 
number of commands/the amount of time required to achieve the desired 
effect. This would set a clear limit and put most terminology issues out 
of the way.

quoted

13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
or "?" background color for Git. And add note that it is easy to script up
porcelanish command, and to add another merge strategy. There also was
example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
marking.

Mostly an implementation detail for "extensible"...

Yup. Any fast-growing SCM can clearly be said to be "extensible", 
otherwise it wouldn't be extended ;-)

[...]

quoted

19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

This one just needs to go. Could possibly be replaced with "Has 
tutorial/documentation online" or some such. No SCM is really intuitive 
to users that haven't experienced any of them before, so the only thing 
that really matters is how much documentation one can find online and 
how up-to-date it is.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

Jakub Narebski wrote:

On 10/27/06, Andreas Ericsson [off-list ref] wrote:

quoted

Horst H. von Brand wrote:

quoted

Jakub Narebski [off-list ref] wrote:

[...]

quoted

I'd rather split "Supports Renames" into engine part (does SCM
remember/detect that rename took place _as_ rename, not remember/detect
it as copiying+deletion; something other than rename) and user 
interface
part: can user easily deal with renames (this includes merging and

viewing file

quoted

quoted

quoted

history).

I think that what to tool does in its guts is completely irrelevant, 
what
is important is what the user sees. Sadly, it seems hard to describe
exactly what is meant/wanted here.

Agreed. I'd rather make the definition "Can users, after a rename has
taken place, follow the history of the file-contents across renames?".
Mainly because this is clearly unambiguous, doesn't involve
implementation details and only weighs what really counts: User-visible
capabilities.

[...]

But equally important for user is another question related to
"Supporting Renames".
Namely detection of renames during merge and detection of conflict 
during merge
is what I would consider minimal "Merge Renames Support". Causing 
information
to be lost is having no "Merge Renames Support". To have "Yes" in this
column SCM
have to resolve conflict at least in obvious cases, and "Yes!" if it
can remember
resolution of merge conflict involving renames ;-).

True.

quoted

IMNSHO, I'd rather have all the features in the list be along the lines
of "Can users/admins/random-boon do X?" and instead of "yes/no" list the
number of commands/the amount of time required to achieve the desired
effect. This would set a clear limit and put most terminology issues out
of the way.

This would make the comparison table less clear, unfortunately.

True that. Perhaps just stick with Yes/No and have a timing table to 
compare merge times, multi-parent merge times and stuff like that.

quoted

quoted

[...]

quoted

19. Ease of Use. Hmmm... I don't know for Git. I personally find it 
very
easy to use, but I have not much experiences with other SCM. I 
wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

This one just needs to go. Could possibly be replaced with "Has
tutorial/documentation online" or some such. No SCM is really intuitive
to users that haven't experienced any of them before, so the only thing
that really matters is how much documentation one can find online and
how up-to-date it is.

For example SCM can be easy to use but at the cost of simplifications
and limited useness.

On the other side basic concept behind some SCM might be more
or less understandable...

Yes, but it will always be based on personal opinion and that's why it 
can never be measured in an unbiased way. It would be like playing 
Trivial Pursuit and getting the question "Which 20'th century author 
wrote the best books?". There's actually two problems with that 
question, but the important one is that it can't be answered correctly 
in this wonderful world we live in where everyone has their own opinion.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

Dear diary, on Fri, Oct 27, 2006 at 04:02:32AM CEST, I got a letter
where "Horst H. von Brand" [off-list ref] said that...

Jakub Narebski [off-list ref] wrote:

quoted

7. Checkouts (as a noun). This probably read "Support Centralized and
Disconnected Centralized Workflow" but that is perhaps too wordy. Git would
have "No" for "Centralized"

Why? We could all agree that some repository is "central" and all push/pull
there. Or send patches by mail (or apply them via ssh). Sure, it's not CVS,
but...

An ability to configure the tool so that the centralized workflow is
_enforced_ may be important for managers. It's stupid, but it's what is
meant there, I think.

quoted

19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...

Extremely subjective. Easy to learn doesn't cut it either.

I don't think this column makes sense at all. I swear I've seen
*several* people that claimed GNU Arch was easy to learn/use for them!

Ilpo Nyyssönen wrote:

"J. Bruce Fields" [off-list ref] writes:

quoted

Documentation helps, though sometimes extensive documentation is a sign
of a problem--it takes a lot more documentation to explain how to manage
a branch in CVS than it does in any sensible system....

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.
Bazaar-NG "branches" is mixture of Git branch and Git repository/clone of
repository. In bzr "branch" refers to abstract SCM concept as part of DAG of
revisions sourced from given revision/head/tip (git branch is very close to
it); yet another but distinct abstract SCM concept of branch as "your" line
of development i.e. path in the DAG of revisions started at given
revision/head/tip and ending in initial/parentless revision; the physical
representation: working area, metainformation, storage or pointer to
storage (when branches share storage forming so called bzr "repository").

About checkout: Bazaar mixes here "CVS checkout" model in the "bzr checkout"
command, and SCM concept of checking-out i.e. getting files from repository
(or branch in bzr) to working area.

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.

But I agree that in Git some terminology (and names of commands) could be
better. Some of it stems from BitKeeper background, some from the way Git
was created: bottom-up, from repository layout to fully (or not ;-) fledged
SCM. For example "pull" as "fetch + merge" is IIRC BitKeeper legacy, while
the fact that "merge" command is low-level (or mid-level) command fairly
poorly usable for user (which should use "pull ." for merging from local
branch).

2. Finding commands.

G: Quite big amount of commands, some clear, but some not so. With all
the installed commands, it is even more confusing. What's the
difference between fetch and pull and which one I should use? Same for
clone and branch.

B: A bit clearer I think, but the pull and merge does cause confusion. 
Also the checkout stuff could be better shown in the command line
help. With plugins like bzrtools the amount of command raises and
confusion increases. Maybe better separation for plugin commands in
the command line help?

In Git Users Survey (http://git.or.cz/gitwiki/GitSurvey) the answer "too
many commands" was most common answer to question 6. "What did you find
hardest?" in the survey (which survey was base on Mercurial survey:
http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey). It would be
perhaps better for Git to clearly divide commands between porcelanish (for
end user), admin (whole repository level) and plumbing (for use in
scripts).

But for example git(7) man page lists git commands clearly divided between
low-level commands (plumbing): manipulation commands, interrogation
commands, synching commands and high level commands (porcelain): main
commands, ancillary commands. The "git help" and "git --help" shows the
most commonly used git commands with short description of each command
("git help -a" show all commands). 
 
I can understand confusion between "git pull" and "git fetch"; it is
adressed in documentation. Although I think the confusion between
"bzr merge" and "bzr pull" is as great if not greater.

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.

3. Understanding output

G: Speaks a language of its own, hard to understand. No progress
reported for long lasting operations.

B: Could maybe speak a bit more. Progress reporting is quite good.

Which long lasting operations lack progress bar/progress reporting?
"git clone" and "git fetch"/"git pull" both have progress report
for both "smart" git://, git+ssh:// and local protocols, and "dumb"
http://, https://, ftp://, rsync:// protocols. "git rebase" has
progress report. "git am" has progress report.

But I agree that Git tends to speak in its own jargon. But this jargon is
very clear if you are familiar with Git. BTW. some of the worst offenders
like <ent> (== <tree-ish>) is removed already from documentation.

4. Misc stuff

G: You have only one workspace and this forces you to use git more or
to make several repositories. 

This is your confusion stemming from Bazaar-NG branch-centricness. In Git
working area is associated with repository, not with branch as in bzr.
Usually you have repsoitory embedded in working area, in .git directory in
top level of working area. The fact that you have only one index (but you
can specify alternate index, or switch between index files), and only one
current branch marker namely HEAD (you can switch HEAD to other branch; if
I remember correctly there is no way to specify current head other way)
makes working with multiple working areas tied to one repository more
difficult. But it is usually not necessary in Git.

In Bazaar-NG "repository" is just sharing the storage of "branches"; in Git
you can share the storage between repositories (although it is not the
default mode), or share common old history between repositories (more
common). 

You can't just diff branchA/foo branchB/foo.

You can: either using "git diff branchA branchB -- foo" which means
difference between branches branchA and branchB limited to the differences
on branch foo (where foo can be directory name or filename), or via
"extended SHA1 reference" using "git diff branchA:foo branchB:foo" which
means compare file/directory "foo" at revision "branchA" and file/directory
"foo" at revision "branchB".

You can even diff two different _repositories_ if they are on the same local
filesystem using pasky trick described in http://git.or.cz/gitwiki/GitTips.

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

Do I have to commit my changes before changing a branch
in the workspace? 

You have to. But we have "git commit --amend", so if I need to do this
I usually do "git commit -m 'TEMPORARY COMMIT'" before switching to other
branch. Or you can save differences between working area and current branch
to patch file. The "git-checkpoint" proposal adresses that... in rather
heavy-handed fashion. There is also "git-stash/git-unstash" floating
somewhere in git mailing list archives.
 

G: What is this git repack thing and do I have to use it? If yes, why? 
Nobody told me that I should run it, but I did notice Linus mentioning
it somewhere. Definetly causing harm for usability.

Hmm... perhaps "repack -a -d" should be shown in "git help" list of commonly
used commands output.

Having two separate formats in repository: loose (but compressed) and packed
(in one file, deltaified, compressed) has the following advantages:

0. Historical, it allowed for git to be released (deployed) early,
originally as fast content tracker and not full SCM, and to add features
based on how people used it and scripted it. It also gave Git design the
advantage of not being tailored/based on some storage mechanism, which
resulted in IMHO very clean design and concepts.

1. Security (together with format). It secures repository against corruption
stemming from: corruption during saving file, race condition, interruptions
during operation etc.; although it doesn' save against all possible errors.
That is what sold Keith on choosing Git as SCM for X.Org:
http://keithp.com/blog/Repository_Formats_Matter.html

2. Efficiency. The packed Git format is both AFAIK the densest repository
format from OSS SCM, and it is very fast to access any given revision.

3. Net format. It allows to use _exactly_ the same format for transmission
during clone and fetch; well with the exception that for "smart" protocols
git can send "thin" pack, with some deltas without bases. The latest work
in progress by Nicolas Pitre and others to convert thin pack to full pack
without exploding it into loose objects in between.


There quite frequently appears suggestion for SCM based on Git, or Git
porcelains (like Cogito) to automatically repack. Latest work on the option
to repack to not pack only loose objects, or repack everything, but to
repack given pack or repack with exception of some archive packs should
help with that solution.

B: People migth misuse the revnos and so be confused when things won't
work like they expected.

Revnos work only with very specific workflows.

Conclusion: I would say that Bazaar is more usable than git.

Conclusion: I would say that Git is more usable than Bazaar.

Jakub Narebski wrote:

quoted

You can't just diff branchA/foo branchB/foo.

You can: either using "git diff branchA branchB -- foo" which means
difference between branches branchA and branchB limited to the differences
on branch foo (where foo can be directory name or filename)

Sorry, it should be:

"limited to the differences on pathname foo (where foo can be directory name
or filename)"

"J. Bruce Fields" [off-list ref] writes:

Documentation helps, though sometimes extensive documentation is a sign
of a problem--it takes a lot more documentation to explain how to manage
a branch in CVS than it does in any sensible system....

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.

2. Finding commands.

G: Quite big amount of commands, some clear, but some not so. With all
the installed commands, it is even more confusing. What's the
difference between fetch and pull and which one I should use? Same for
clone and branch.

B: A bit clearer I think, but the pull and merge does cause confusion. 
Also the checkout stuff could be better shown in the command line
help. With plugins like bzrtools the amount of command raises and
confusion increases. Maybe better separation for plugin commands in
the command line help?

3. Understanding output

G: Speaks a language of its own, hard to understand. No progress
reported for long lasting operations.

B: Could maybe speak a bit more. Progress reporting is quite good.

4. Misc stuff

G: You have only one workspace and this forces you to use git more or
to make several repositories. You can't just diff branchA/foo
branchB/foo. You can't just open file from old branch to check
something while you are developing in some new branch. Do I have to
commit my changes before changing a branch in the workspace?

G: What is this git repack thing and do I have to use it? If yes, why? 
Nobody told me that I should run it, but I did notice Linus mentioning
it somewhere. Definetly causing harm for usability.

B: People migth misuse the revnos and so be confused when things won't
work like they expected.

Conclusion: I would say that Bazaar is more usable than git.

Jakub Narebski [off-list ref] writes:

Ilpo Nyyssönen wrote:

quoted

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.

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.

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.

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.

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.

quoted

G: You have only one workspace and this forces you to use git more or
to make several repositories. 

This is your confusion stemming from Bazaar-NG branch-centricness. In Git
working area is associated with repository, not with branch as in bzr.

Exactly my point.

quoted

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.

quoted

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

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.

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