[Top][All Lists]

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

Re: [Bug-cssc] Test binary/auto.sh fa11

From: James Youngman
Subject: Re: [Bug-cssc] Test binary/auto.sh fa11
Date: Sun, 22 May 2011 15:28:39 +0100

On Sun, May 22, 2011 at 2:12 PM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>> > I am talking about "star", when I mean the oldest OSS tar implementation I
>> > started to write in 1982. GNU People use the name "tar" when they are 
>> > talking
>> > about gtar (formerly known as PD-tar and SUG-tar)
>> If the distinction is important and not implied in the context, they
>> say GNU tar.
> I did see "tar" many times when "gtar" would have been more apropriate.
>> > isn't this confusing people
>> > much more than using the name SCCS for the only SCCS (derived from Marc J.
>> > Rochkind's implementation) that is still under active development?
>> I'm not sure how illustrating potentially-confusing usage elsewhere
>> makes a point about SCCS implementations.
> I just wanted to show that there are examples where people use a name even
> though the code was not derived from the original and that there seem to be
> more confusion in these cases.
>> > If you have a good idea for a naming method that matches the constraintsm 
>> > you
>> > are welcome!
>> I'm not aware of any constraints.    I was reluctant to suggest a
>> specific usage out of delicacy over your preferences.   But if you
>> insist on hearing a suggestion, it would be this:
>> Schily SCCS - taken from http://sccs.berlios.de/ - refers to your
>> implementation.
>> <vendor> SCCS - refers to a SCCS implementation shipped at some point
>> by Unix vendor <vendor>.
> The problem here is that using <vendor> <product> makes people believe that
> this is really a product that is completely different because there is no
> common code.

People don't assume that HPUX's ksh shares no common code with AIX's
ksh.   People don't assume that Red Hat Linux shares no common code
with SUSE Linux.   etc, etc.    There is no reason why people would
implicitly assume that Schily SCCS shares no code with HPUX SCCS.  And
no reason to assume that it does either, I suppose.

>> Obviously there are other implementations too but they have specific
>> names already:
>> CSSC - clearly unambiguously refers to the GNU implementation I
>> maintain.   If this forks, I guess "GNU CSSC" is more specific.
>> MySC - Ross Ridge's implementation
>> BitSCCS - Larry's implementation
>> NSE, Teamware - from Sun
>> Sablime - from Alcatel/Lucent
>> Where it's material, all of these above can be qualified with a
>> release identifier (or Unix release in the case of <vendor> SCCS).
> CSSC and KitKeeper SCCS do not cause wring impressions as they have been
> written indepently (even though Larry from BitKeeper had access to the 
> original
> code).
> NSE and Teamware "are" not SCCS. They just use SCCS.
> I do not see a nice way to mention that SCCS is not something I have written
> but that I seem to be the current maintainer.

I just suggested one way.   Or use whatever name you choose.  But just
saying SCCS is simply too ambiguous.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]