Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: git copies of cvs modules available

2009/10/28 Greg A. Woods <>:
> At Tue, 27 Oct 2009 23:02:00 +0100, Michal Suchanek 
> <> wrote:
> Subject: Re: git copies of cvs modules available
>> 2009/10/14 Rhialto <>:
>> > 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

Home | Main Index | Thread Index | Old Index