On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:
quoted text
> Horst H. von Brand wrote:
>> Jakub Narebski <jnareb@gmail.com> 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
quoted text
>>> 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 ;-).

quoted text
> 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 text
>>> 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 text
>> [...]
>>
>>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html