info-cvs
[Top][All Lists]
Advanced

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

Re: [To CVS-Dev] CVS Directory Order and sanity.sh


From: Wayne_Johnson
Subject: Re: [To CVS-Dev] CVS Directory Order and sanity.sh
Date: Mon, 29 Jan 2001 12:32:20 -0600


You earned your pay for the week.

MVS does support strcoll() as most recent Posix.1 systems do, of course that
doesn't guarantee that all CVS platforms do so it looks like I'll have to create
a conditional for strcoll.

Thanks.





Eric Siegerman <address@hidden> on 01/25/2001 05:36:45 PM

To:   address@hidden
cc:    (bcc: Wayne Johnson/MINN/Candle)
Subject:  Re: [To CVS-Dev] CVS Directory Order and sanity.sh



On Thu, Jan 25, 2001 at 05:23:37PM -0500, Larry Jones wrote:
> > > 2) It seems that quite often the order that files are processed is
different on
> > > MVS.  For example, in basicb-7, the output that is expected is:
> > >  'T Emptydir/sfile1
> > > T sdir2/sfile2'
> > >
> > > but on MVS it's:
> > > 'T sdir2/sfile2
> > > T Emptydir/sfile1'
> > >
> > > I am assuming that the change is due to a different collating sequence
between
> > > ASCII and EBCDIC.  My question is, shouldn't LC_COLLATE=C fix this?  I
looked in
> > > the opendir/readdir function descriptions on several different UNIX
(UNII?) and
> > > LINUX docs and none mention the order that these files/directories should
be
> > > listed, nor use of LC_COLLATE.
>
> In general, readdir() returns entries in whatever order they are
> physically stored in the directory, it does no sorting of any kind.

Correct.

> (In the case of basicb-7, for example, I think the
> subdirectories should be processed in the order they occur in
> CVS/Entries, which should be the order they were added in.)

Nope; CVS does them in alphabetical order (as it seems to do just
about everything except "import").  Tested by creating and "cvs
add"ing subdirectories in non-alphabetical order, hand-editing
CVS/Entries into a different non-alphabetical order, then doing
"cvs tag foo".

But CVS doesn't seem to do locale-based sorting.  It uses
strcmp(), which just does a byte-for-byte numeric comparison.
This would explain the reported output; in EBCDIC, lower-case
letters do indeed sort before caps ('a' is 0x81; 'A' is 0xC1).  A
quick grep for "sort" in the CVS 1.11 sources turns up at least
three functions that need changing:
     history.c:sort_order
     modules.c:sort_order
     hash.c:fsortcmp

Solaris provides strcoll() and strxfrm() to do locale-based
string comparisons, but I have no idea how standard they are.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense.  But I'm a Sagittarius,
so I'm naturally skeptical.

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs







reply via email to

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