From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:05
On Mon, 7 Jan 2008, Shlomi Fish wrote:
I'm CCing all the correspondents, because I'm banned from the vger.kernel.org
mail. This has been an obstacle for me in several legitimate occassions and
this one is the latest. I'm still CCing it, so the people in the mailing list
will receive the replies.
On Monday 10 December 2007, Jakub Narebski wrote:
quoted
I have noticed that your SCM comparison at "Better SCM Initiative"
website
http://better-scm.berlios.de/comparison/comparison.html
misses one of the Git, version control system which is used to manage
Linux kernel, and one of the main open source (distributed) version
control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).
Indeed git is absent. That's because no one until you has volunteered to send
a patch that adds it to the comparison. Another requirement is for someone to
volunteer to become a "champion" for the version control system and maintain
it into the future. So who is going to be the champion?
I can be git champion for "Better SCM Initiative" comparison... although
I'd rather somebody else was it.
[...]
quoted
Below there is (slightly doctored) patch to the sources for the site.
Despite the fact that I the comparison was recently patched to add Bazaar and
fix some grammatical problems, the patch still applies cleanly. However, I
saw that some people commented on it here. Can you send me a new patch
integrating all this commentary?
I'll try to send revised patch soon. Integrating commentary is a bit
harder that it could be because some responses were sent _only_ to
git mailing list, so I'd have to browse through git mailing list
archives.
BTW. some of the questions / comments were caused by the fact that the
features listed in Better SCM Initiative: Comparison are a bit ambiguous.
What does for example "Atomic Commit" mean? Does it mean that if we
interrupt commit in the middle we would always get full commit or none,
and not some f**d-up intermediate state? Hos CVS can have atomic commits
then?
What does "Renames Support" mean? Does it mean that when browsing history
we [can] show file / directory renames? Does it mean that log of file or
directory history [can] follow renames? Does it mean that line-wise file
history [can] follow renames? Renames support in merges is as TODO, so
I don't think that this one matters in this question. Because the answer,
especially in the case of git which is a bit different in that it does
rename detection and not rename tracking (using inodes / file-ids),
depends on that...
--
Jakub Narebski
Poland
On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
What does "Renames Support" mean?
Accordingly to the clarification provided there, it means retaining the
history of the file when its name changed. So I would write like this:
Yes. Git can automatically detects renames and show history together,
however being content oriented rather than file oriented, the notion of
"retaining the history of the file" can not exactly applied to it.
Because the answer,
especially in the case of git which is a bit different in that it does
rename detection and not rename tracking (using inodes / file-ids),
depends on that...
Git is different in that it tracks the content as the whole rather than
tracking a set of files. When you look at some source code, what you
really want to know who and why wrote *this*, and usually it does not
matter to you whether it was written in this file or another one. CVS
is really bad at that, because if you renamed a file, it would be very
difficult to go back to history and find that. Many file-ids based SCMs
have solved this problem, however, they do not do any better than CVS
in another very common case -- when your code is moved around as result
of refactoring, but Git addresses both problems, not just one!
So, it is not as much about explicit renaming vs automatic, but about
different design goals. After finishing reading this questionnaire,
it seems to me that a more proper title for it would be "Better CVS
Initiative", so it is not surprisingly that Git does not fit into it
well. It is like trying to put characteristics of your LCD into a
questionnaire for CRT monitors -- some does not make sense, other
misleading, and most important ones are not mentioned anyway...
Dmitry
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:05
On Mon, 14 January 2008, Dmitry Potapov wrote:
On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
quoted
What does "Renames Support" mean?
By the way, the question was to the author of Better SCM Initiative
Comparison, Shlomi Fish.
Accordingly to the clarification provided there, it means retaining the
history of the file when its name changed. So I would write like this:
Yes. Git can automatically detects renames and show history together,
however being content oriented rather than file oriented, the notion of
"retaining the history of the file" can not exactly applied to it.
"History of a file" can be defined as "<scm> log 'file'", and this is
well defined also for git. And 'rename support' for file means just
that this history of a file (of a current file contents) follows file
renames.
IIRC this des not work for directories... but on the other hand git,
tracking contents only as a goal, does not track directories.
quoted
Because the answer,
especially in the case of git which is a bit different in that it does
rename detection and not rename tracking (using inodes / file-ids),
depends on that...
Git is different in that it tracks the content as the whole rather than
tracking a set of files. When you look at some source code, what you
really want to know who and why wrote *this*, and usually it does not
matter to you whether it was written in this file or another one. CVS
is really bad at that, because if you renamed a file, it would be very
difficult to go back to history and find that. Many file-ids based SCMs
have solved this problem, however, they do not do any better than CVS
in another very common case -- when your code is moved around as result
of refactoring, but Git addresses both problems, not just one!
AFAIK Mercurial (hg) is not file-id based, but does explicitely track
renames. There was even an idea presented on git mailing list to mark
renames in commit object in some "note" header.
So, it is not as much about explicit renaming vs automatic, but about
different design goals. After finishing reading this questionnaire,
it seems to me that a more proper title for it would be "Better CVS
Initiative", so it is not surprisingly that Git does not fit into it
well. It is like trying to put characteristics of your LCD into a
questionnaire for CRT monitors -- some does not make sense, other
misleading, and most important ones are not mentioned anyway...
Please remember that AFAIK this table is _older_ than Git itself.
But it is a fact that some characteristics are much patterned after
CVS features and misfeatures.
It would be much better if for each feature there was some test
described which would allow to check if the feature is supported.
By the way, even before "git log --follow" you could have "this file
was renamed to that file" in the commit/revision patchset. This is
IMHO enough of rename support. Much more important is correct support
for renames in merges, which is in TODO for Better-SCM comparison...
--
Jakub Narebski
Poland
On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:
On Mon, 14 January 2008, Dmitry Potapov wrote:
quoted
Yes. Git can automatically detects renames and show history together,
however being content oriented rather than file oriented, the notion of
"retaining the history of the file" can not exactly applied to it.
"History of a file" can be defined as "<scm> log 'file'", and this is
well defined also for git.
You missed the key word here -- *retaining*. In fact, if you define the
history of a file just as something what "<scm> log" produce then what
is the problem with CVS here? Why do most people say that CVS does not
retain file history over rename? Certainly, you can type "cvs old-name"
and see history of one file, and if you type "cvs new-name" then history
of another... But somehow most people think about these two pieces as
being the history of *one* file... So, your definition is incorrect or,
at least, very different from what most people mean by that.
BTW, when you type "git log 'file'", it shows you not history of a file,
but history of changes that affect the specified paths...
And 'rename support' for file means just
that this history of a file (of a current file contents) follows file
renames.
To equate a file with its contents is like to equate a variable with
its value. They are not exactly the same. If you renamed a file and
completely changed its contents, is it still the same file or not?
If you think about file as being inode then the answer is yes, but if
look at its content then the answer is no.
Git tracks contents, while many other SCMs tracks files regardless of
their contents. So, Git can show the history of file contents, but
not the history of a file...
IIRC this des not work for directories...
Git works for directories, it is just that the --follow option cannot
applied to it, because this option means to follow the file contents,
which does not make much sense for directories.
but on the other hand git,
tracking contents only as a goal, does not track directories.
Exactly.
quoted
Git is different in that it tracks the content as the whole rather than
tracking a set of files. When you look at some source code, what you
really want to know who and why wrote *this*, and usually it does not
matter to you whether it was written in this file or another one. CVS
is really bad at that, because if you renamed a file, it would be very
difficult to go back to history and find that. Many file-ids based SCMs
have solved this problem, however, they do not do any better than CVS
in another very common case -- when your code is moved around as result
of refactoring, but Git addresses both problems, not just one!
AFAIK Mercurial (hg) is not file-id based, but does explicitely track
renames. There was even an idea presented on git mailing list to mark
renames in commit object in some "note" header.
I suspect the main reason why Mercurial support that is that a lot of
programmers whose mind was mangled by many years of CVS experience asked
for that feature. In practice, what you really want to track is contents.
And it is not difficult to add some "note" to the commit and teach Git to
follow it, but I don't see any practical value in that...
quoted
So, it is not as much about explicit renaming vs automatic, but about
different design goals. After finishing reading this questionnaire,
it seems to me that a more proper title for it would be "Better CVS
Initiative", so it is not surprisingly that Git does not fit into it
well. It is like trying to put characteristics of your LCD into a
questionnaire for CRT monitors -- some does not make sense, other
misleading, and most important ones are not mentioned anyway...
Please remember that AFAIK this table is _older_ than Git itself.
But it is a fact that some characteristics are much patterned after
CVS features and misfeatures.
Well, if it is so old, that explains why it gave me such impression...
It would be much better if for each feature there was some test
described which would allow to check if the feature is supported.
Wanna test your LCD monitor with some old CRT tests? -:)
By the way, even before "git log --follow" you could have "this file
was renamed to that file" in the commit/revision patchset.
You could write that in CVS message too, but I don't think it can
be considered as retaining the history of the file...
Dmitry
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:05
Dnia poniedziałek 14. stycznia 2008 07:58, Dmitry Potapov napisał:
On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:
quoted
On Mon, 14 January 2008, Dmitry Potapov wrote:
quoted
Yes. Git can automatically detects renames and show history together,
however being content oriented rather than file oriented, the notion of
"retaining the history of the file" can not exactly applied to it.
"History of a file" can be defined as "<scm> log 'file'", and this is
well defined also for git.
You missed the key word here -- *retaining*. In fact, if you define the
history of a file just as something what "<scm> log" produce then what
is the problem with CVS here? Why do most people say that CVS does not
retain file history over rename? Certainly, you can type "cvs old-name"
and see history of one file, and if you type "cvs new-name" then history
of another... But somehow most people think about these two pieces as
being the history of *one* file... So, your definition is incorrect or,
at least, very different from what most people mean by that.
I assume that 0th part of rename support is true, i.e. that we can
recover previous full-tree state of repository.
BTW, when you type "git log 'file'", it shows you not history of a file,
but history of changes that affect the specified paths...
The fact that in "git log <path>" the <path> part is path _limiter_
(and can be directory, or set of directories) rather than being limited
to simply single filename is what makes git different, both in good
("git log subsystem/path") and in bad (different from what other SCM
used to) way.
When you type "git log --follow='file'", it shows you history of
a _contents_ which currently is in 'file'; even if there were rename
in the history of 'file' somewhere in the past.
When you type "git log 'directory'", it shows you (simplified) history
of changes affesting specified directory (usually some subsystem).
IMHO "rename support" should be defined as
1.) showing renames when examining given revision (status, log, show;
whatever it is called).
2.) it should be able to follow history of a file when it looks like
this: add, change, rename, change.
quoted
And 'rename support' for file means just
that this history of a file (of a current file contents) follows file
renames.
[...]
quoted
IIRC this des not work for directories...
Git works for directories, it is just that the --follow option cannot
applied to it, because this option means to follow the file contents,
which does not make much sense for directories.
But it would be nice to have somehow "git log --follow=directory" work,
even if directory in which susystem resides was renamed. It is harder
work also because (I think) directories are more often split and joined
than file[s contents].
quoted
quoted
Git is different in that it tracks the content as the whole rather than
tracking a set of files. When you look at some source code, what you
really want to know who and why wrote *this*, and usually it does not
matter to you whether it was written in this file or another one. CVS
is really bad at that, because if you renamed a file, it would be very
difficult to go back to history and find that. Many file-ids based SCMs
have solved this problem, however, they do not do any better than CVS
in another very common case -- when your code is moved around as result
of refactoring, but Git addresses both problems, not just one!
AFAIK Mercurial (hg) is not file-id based, but does explicitely track
renames. There was even an idea presented on git mailing list to mark
renames in commit object in some "note" header.
I suspect the main reason why Mercurial support that is that a lot of
programmers whose mind was mangled by many years of CVS experience asked
for that feature. In practice, what you really want to track is contents.
And it is not difficult to add some "note" to the commit and teach Git to
follow it, but I don't see any practical value in that...
Mercurial can be IMHO from architecture point of view be viewed a bit
as "CVS done right", much more than Subversion, with its path-hashed
changeset storage, manifest file, and changelog / changerev file.
And I guess that Mercurial supports this because of the most important
part of "renames support" (which is present only as TODO for Better-SCM
comparison), namely merging correct files in presence of renames.
quoted
It would be much better if for each feature there was some test
described which would allow to check if the feature is supported.
Wanna test your LCD monitor with some old CRT tests? -:)
If those tests were done correctly, not from technical side ("renames
support" and other similar thingies for SCMs, refresh rate for LCD/CRT),
but from user side (does command which shows history of a file follows
renames, eyestrain / image sharpness for monitors).... :-)
--
Jakub Narebski
Poland