Re: git copies of cvs modules available

[Michal Suchanek <hramrach%centrum.cz@localhost>]

2009/10/28 Greg A. Woods <woods%planix.ca@localhost>:
> At Tue, 27 Oct 2009 23:02:00 +0100, Michal Suchanek 
> <hramrach%centrum.cz@localhost> wrote:
> Subject: Re: git copies of cvs modules available
>>
>> 2009/10/14 Rhialto <rhialto%falu.nl@localhost>:
>> > Yes, but the $Id$ that it supports is a hash value which is absolutely
>> > meaningless to a human reader.
>>
>> Not that the CVS version is much more meaningful.
>
> Note the key phrase here is "human reader".
>
> A CVS identifier number not really truly meaningful in a direct sense of
> course, but it is easily recognisable, and an average human reader can
> easily (i.e. on a glance) compare RCS/CVS/SCCS style version identifiers
> without any real effort whatsoever.
>
> That's just not possible with a long hash string.
>
>
>> When the file "escapes from" a VCS the version number is meaningless.
>
> Well, "meaningless" outside the VCS only in the most strict sense.
>
> In day-to-day reality the simple-form RCS/CVS/SCCS version identifiers
> can still work without effort for the _human_ reader when one is dealing
> with RCS/CVS/SCCS-style central (authoritative) repositories.
>
> Key here though is of course that with a central authoritative
> repository you don't need a VCS "context" in which to compare the
> simple-form RCS/CVS/SCCS style version identifiers. ÂThey are easy to
> compare in any context, even without any access to the repository,
> because for a given file they all originate from the same source.
>
> Of course once it gets down to the assignment of real meaning to the
> identifier, i.e. the kind of meaning I think you were actually talking
> about, then you do effectively need the repository, especially with CVS,
> because any branch numbers are meaningful only with the context of one
> file and so you need the related tag identifiers to compare them with
> any other files. ÂHowever this use is far more rare in my experience