On 10/27/06, Andreas Ericsson <ae@xxxxxx> wrote:
Horst H. von Brand wrote:
Jakub Narebski <jnareb@xxxxxxxxx> 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.
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.
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.
[...]
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html