Re: VCS comparison table

[Andreas Ericsson <ae@op5.se>]

Jakub Narebski wrote:
> On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:
>> 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
>>>> 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.

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

> 
>>> [...]
>>>
>>>> 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