[Top][All Lists]

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

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

From: Joerg Schilling
Subject: Re: [Bug-cssc] Test binary/auto.sh fa11
Date: Sun, 22 May 2011 15:12:18 +0200
User-agent: nail 11.22 3/20/05

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.

> 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 

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.

> > Regardless of what POSIX says, the SCCS weave delta format does not allow to
> > deal with unencoded data that does not end in a new line.
> >
> > A test similar to what you coded makes sense - I just would like to see a 
> > test
> > that matches the behavior of SCCS.
> Your implementation of SCCS, you mean?

The specific feature I was referring to has been introduced by Sun.
It is however available in my version too.


 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

reply via email to

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