sandbox on NFS-mounted directory?

[Terrence Enger]

Greetings,

I have seen lots of warnings against accessing a repository
through an NFS mount.  But I do not remember seeing any
comments about accessing a sandbox through an NFS mount.
(Although, until today, I did not think I cared, so could
easily have overlooked warnings.)  I would welcome your
advice.

BTW, Cederqvist 1.12.12 pages 97, 156, and 175 talk without
warnings about "checkouts over NFS" and so forth, Are the
earlier warnings in this group outdated?

Cheers,
Terry.




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

access to cvshome

[Terrence Enger]

Greetings,

I have the feeling that I may have seen the answer to this
question here lately, but I cannot find it now.  Please
accept my apologies if this is a repeat.

What is the method for read access to the source repository
at cvshome.org?

still describes :pserver: access.  Meanwhile, :ext: via ssh
rejects the userid and password with which I registered at
cvshome.org.

Thank you, all, for your attention.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

dangers of ctrl-z in text files

[Terrence Enger]

Greetings.

In a recent posting to info-cvs, I pointed out the need to
flag as binary any file which might contain a byte with the
value decimal 26, a.k.a. ctrl-z.  Then I sat down to write
some words for chapter 9 of the Cederqvist, and I find that
I still have a little bit to learn.  Can somebody
help me with these questions?

(*) I have just demonstrated the problem using 
Client: Concurrent Versions System (CVS) 1.11.4
(client)
running under Windows ME.  Can you tell me how other
clients behave in this respect?  Do references to other
clients belong in the Cederqvist, anyway?

(*) I know about ctrl-z marking end-of-file on Microsoft
operating systems.  Are there other operating systems
having this or a similar dangerous feature?

(*) Does cvs server on a MS operating system have the same
problem with the repository files?

(*) Where should the new paragraph go within Chapter 9:
  - Early (second paragraph) in 9.1 "The issues with
binary files", because getting your data back is a
really basic function?
  - Last in 9.1, because only people using or targeting
a Microsoft operating system care.

(*) Here are the "some words" so far.  I invite comments.

The most basic function of a version control system
is the ability to retrieve the files that the user
puts into the system.  Users importing [Terry: 
demonstrate this] or committing binary files from 
a client running on a Microsoft operating system 
may fail to get their data into the repository if
they forget to flag a binary file as binary.  The
problem arises when you put into the repository a
file containing a byte value of ctrl-z or 26
decimal.  Reading this file in text mode, cvs sees
that byte as an end-of-file marker; any following
data does not go into the repository.  The problem
is particularly pernicious as both the checkin and
checkout execute without any indication of a
problem.  Perhaps only the attempt actually to use
the file will reveal that data has been lost.


On the other hand, is there a program change we could make
to mitigate the problem?

(*) If a checkout gives a file like it was checked in on the
same platform (the ctrl-z, following data, and the same
length in the directory entry), it would be hard to say
that the behaviour is wrong.  Could there by anybody
relying on the old behaviour?

(*) Could we give a message for a "damaged" checkin?  What
severity?

(*) Is it possible to accomplish either of these without
adding undesirable platform-specific code to cvs?


Thank you all for your attention.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Why I am not getting the files imported

[Terrence Enger]

At 05:17 2003-12-15 -0800, Kayed Alfi wrote:
> All:
>
> I have imported a populated directory into my
> respository.  I work on WinCVS 1.3.  The files (*.doc
> and *.fmb)  imported fine.  When I tried to checkout
> the files, I get only 1KB of file sizes?
>
> I run on pserver authentication mode, does this have
> to do any thing with admin privilages?  Please help
>
> Thanks,

The last time I had a problem like this was back when I was
using bare-naked rcs.  I did my damage during the checkin,
although it only became apparent during the checkout.  So
your problem may be a different one.  Anyway, here are my
thoughts.

Windows, alas, has two ways of recognizing end of a file.
If you have a byte value of decimal 26 in your data, you
must process the file in binary mode.  The file cvswrappers

can make this easier for files you add to the repository
hereafter.  You can mark the file as binary in the
repository using cvs admin
.
Then, of course, you have to fix up any sandboxes having the
file.

HTH.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: revision/version numbers

[Terrence Enger]

At 16:10 2003-10-31 -0500, Donald Sharp wrote:
> Why do you need this?  What is important is the label!
>
> If you can't convince them that it's not terribly important
> pull a workspace over the release label and do a cvs status -R
> and parse the output.

Or, list the various CVS/Entries files.  Let the QA team do
their own parsing.

As an additional inducement to help your QA team give up on
this request, show them how easy it is to see in detail the
changes between two tags.

Terry.


>
> donald
> On Fri, Oct 31, 2003 at 03:56:47PM -0500, Katherine King wrote:
> > Hi,
> > 
> > I am pretty much a beginner to CVS, but somehow "becoming" the expert
on the
> > team, and this is now causing me to need to ask for some help.  We have a
> > CVS repository, and we are working with branches and tags, no problem.
But
> > we need a little more information about revision numbers for the quality
> > assurance team.  I have been able to get this for the main branch by
locking
> > the tree - this shows the version/revision numbers (cvs admin -l), but I
> > need the version/revision numbers for all the files with a certain tag.
 Is
> > there a way to do this?
> > 
> > Sorry if this is a silly question, but I haven't been able to find it.
> > 
> > Thanks
> > Kate




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Conflict committed

[Terrence Enger]

At 09:07 2003-10-29 -0800, Mark D. Baushke wrote:
>
>It is not up to cvs to determine what data patterns should or should not
>be allowed to be committed into a file.
>

Indeed, I routinely commit conflicted files after applying vendor
updates.  Tag this state (with log messages distinguishing conflicted
files from other updated files), then tag again after I resolve
conflicts, then after successful compile and link, and so forth.  Just
comes from being anal-retentive, I guess.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

the Cederqvist, difficulty downloading .pdf

[Terrence Enger]

Greetings,

I have just visited ,
and I tried to download the pdf file of the Cederqvist for
release 1.12.2
.
A number of problems or mysteries ...

  - The result is a file of only 539,920 bytes, compared to
over a megabyte for the 1.12.1 version.

  - The download completed faster than my dialup connection
can transfer half a megabyte.

  - Acrobat reader complains "There was an error opening
this document. The file is damaged and could not be
repaired."  

Has anyone else succeeded lately in downloading and opening
the .pdf of the Cederqvist?  If so, I shall assume that the
error is something uninteresting at my end.

Meanwhile, I shall carry on with my attempts to regenerate
this from the source (which is what I really want to
(learn to) do, anyway).

Thank you, all, for your attention.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Bug tracking.

[Terrence Enger]

At 11:15 2003-09-30 -0400, "Zieg, Mark" <[EMAIL PROTECTED]> wrote:
[snip]
>
>You can do that easily with "cvs update -j ... -j ..." as long as you
create a tag each time you do the synchronization, or you can use something
like my  to extract a patchfile
after-the-fact.

I think I shall try some of the scripts there.  But, tell me, why ?

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs diff, proposal for change

[Terrence Enger]

At 15:56 2003-09-04 -0400, "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
>[ On Wednesday, September 3, 2003 at 13:07:52 (-0400), Terrence Enger
wrote: ]
> > Subject: cvs diff, proposal for change
> >
> > In general, the concensus of those in the know has been
> > negative: cvs diff is so far from working with arbitrary files
> > that it is not even worth thinking about changing it.
> > Nevertheless, I beg your indulgence as I put forward this
> > preliminary proposal for changes.
>
> "cvs diff" itself is just the very tip of the iceberg.
>
> The same text-based delta algorithms go right to the core of how RCS
> files work.

I would not dream of suggesting a change to that.  Nor do I suggest
changing anything in the repository, or even in a sandbox.

> 
> If you want to store abitrary (and especially unstructured) binary data
> in a version control system then CVS (and RCS) never was, and never will
> be, an appropriate choice for your purposes.
>

Yes, but (in my best, 3-year-old, obnoxious whine) ...
(1) I have some familiarity with cvs, and I am learning to
like it more all the time.
(2) I have binary files, and  lack of version
control of binary files has wasted too much of my
time.
Just like any 3-year-old, I don't want to admit that I am
SOL.

cvs already supports binary files to the extent of offering
-kb.  And Herr Klauer's files are binary only in the sense
that different patterns look the same on the screen.  Would
the objection to the proposal still stand if I could submit
a patch?  (I am not planning to do that soon, and probably
not at all; just probing for the roots of the objection.)

Meanwhile, I am going away to think some more.

Thank you, Greg, for your attention.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs diff, proposal for change

[Terrence Enger]

This is my second attempt to post this question.  The first
has not appeared on the list; neither have I received a
bounce message.  Please accept my apology if you receive it
twice.

Greetings, all.

I keep seeing questions and comments in the list about cvs
diff, especially about how it is not useful for files holding
data other than plain text.  I see even Andreas Klauer's
recent question "normalizing files and old revisions"
()
as a variation on this theme.

In general, the concensus of those in the know has been
negative: cvs diff is so far from working with arbitrary files
that it is not even worth thinking about changing it.
Nevertheless, I beg your indulgence as I put forward this
preliminary proposal for changes.

Note that different parts of the proposal address different
situations.  Indeed, I expect that I shall write contradictory
or incompatible statements as I transcribe this message from
the scribblings on my whiteboard.  Hey, this proposal is
*very* preliminary.


One common situation is a file which can be converted to plain
text on which the output of diff is informative.  Such a case
is my current excuse for procrasting about programming
, and Herr Klauer's problem could be addressed this
way, too.  So ...

(*) "cvs diff" and "cvs rdiff" accept optional arguments
--filter1=, --filter2=,
--filter-both=.

(*) Then, in the introduction to the diff output of each file,
after the line "retrieving revision ", cvs
prints a line "filtering  through "
if applicable.

(*) In the introduction to the diff output of each file,
within the line "diff  ", cvs inserts after
 or  " (filtered )" as
appropriate.

(*) For each rev with  specified, cvs invokes
 as a filter before going getting into the
meat of the diff.


Often, the above is not adequate, and I agree that cvs cannot
then do a useful comparison.  Still, we could exploit existing
code (and its documentation) to help user-supplied programs
interpret command-line arguments in the expected way ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
--diffproc=.

(*) Then, for each pair for files which are bitwise different,
cvs calls  with arguments naming (checked
out) files to be compared plus all the information which
existing program displays in the per-file header of diff
output.


I can easily imagine wanting to avoid option fatigue by
defaulting filters based on the filename.  The syntax of the
administrative file commitinfo seems to recommend itself.  But
where, oh where, should the user put her preferences?  I have
assumed implicitly that filters and comparison programs are
distinct from cvs itself, so they may not exist or may not
work on any particular client machine, so they do not belong
among the administrative files.  One can imagine file formats
where one would want to develop a filter or comparison program
as part of the project, but I think this case is more the
exception than the rule.  The quantity of information is
greater than what one commonly assigns to an environment
variable.  .cvsrc applies to one user on one client machine,
which seems good; but the existing syntax does not allow
options to be sensitive to filename.  Perhaps we have to
define a new run-control file?  Anyway ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
--no-filter to prevent invocation of otherwise applicable
filters or comparison programs.


I am not nearly ready to start work on changes of this scope,
but I would appreciate your comments, questions, et cetera.


Thank you all for your attention.

Terry.  
Available for contract programming.  
(As if you couldn't guess from the length of this message
.)




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs diff, proposal for change

[Terrence Enger]

Greetings, all.

I keep seeing questions and comments in the list about cvs
diff, especially about how it is not useful for files holding
data other than plain text.  I see even Andreas Klauer's
recent question "normalizing files and old revisions"
()
as a variation on this theme.

In general, the concensus of those in the know has been
negative: cvs diff is so far from working with arbitrary files
that it is not even worth thinking about changing it.
Nevertheless, I beg your indulgence as I put forward this
preliminary proposal for changes.

Note that different parts of the proposal address different
situations.  Indeed, I expect that I shall write contradictory
or incompatible statements as I transcribe this message from
the scribblings on my whiteboard.  Hey, this proposal is
*very* preliminary.


One common situation is a file which can be converted to plain
text on which the output of diff is informative.  Such a case
is my current excuse for procrasting about programming
, and Herr Klauer's problem could be addressed this
way, too.  So ...

(*) "cvs diff" and "cvs rdiff" accept optional arguments
--filter1=, --filter2=,
--filter-both=.

(*) Then, in the introduction to the diff output of each file,
after the line "retrieving revision ", cvs
prints a line "filtering  through "
if applicable.

(*) In the introduction to the diff output of each file,
within the line "diff  ", cvs inserts after
 or  " (filtered )" as
appropriate.

(*) For each rev with  specified, cvs invokes
 as a filter before going getting into the
meat of the diff.


Often, the above is not adequate, and I agree that cvs cannot
then do a useful comparison.  Still, we could exploit existing
code (and its documentation) to help user-supplied programs
interpret command-line arguments in the expected way ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
--diffproc=.

(*) Then, for each pair for files which are bitwise different,
cvs calls  with arguments naming (checked
out) files to be compared plus all the information which
existing program displays in the per-file header of diff
output.


I can easily imagine wanting to avoid option fatigue by
defaulting filters based on the filename.  The syntax of the
administrative file commitinfo seems to recommend itself.  But
where, oh where, should the user put her preferences?  I have
assumed implicitly that filters and comparison programs are
distinct from cvs itself, so they may not exist or may not
work on any particular client machine, so they do not belong
among the administrative files.  One can imagine file formats
where one would want to develop a filter or comparison program
as part of the project, but I think this case is more the
exception than the rule.  The quantity of information is
greater than what one commonly assigns to an environment
variable.  .cvsrc applies to one user on one client machine,
which seems good; but the existing syntax does not allow
options to be sensitive to filename.  Perhaps we have to
define a new run-control file?  Anyway ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
--no-filter to prevent invocation of otherwise applicable
filters or comparison programs.


I am not nearly ready to start work on changes of this scope,
but I would appreciate your comments, questions, et cetera.


Thank you all for your attention.

Terry.
Available for contract programming.
(As if you couldn't guess from the length of this message
.)




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Howto?

[Terrence Enger]

At 16:11 2003-08-14 +0300, Stephen Biggs wrote:

[point 1 snipped]

>2. If I checkout a module from one repository, say from the Internet,
>and then import it into a second repository, say my local one, is there
>an easy and correct way to make sure that the local copy is also updated
>by the changes in the remote repository?  That is, I want to do an
>update from the remote repository in my local directory and then be able
>to merge and commit those changes to my local repository?

I am doing something very like this, using some bash and perl scripts.  
The scripts are still evolving, and are peculiar to my own situation, 
with hardcoded repositories, module names, tags, and so forth.  The 
only documentation is the scripts themselves.  Nevertheless, if you 
are interested in them, I can send you a copy.  If you can imagine a 
way to make the scripts more widely useful, I am willing to apply GPL 
to them.

>
>Thanks for any help.
>

You are welcome.  I just hope it does help a little bit.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Invalid reply from auth server

[Terrence Enger]

Greetings, all

Suddenly, this morning, I get a bunch or error messages when I try to cvs
update my sandbox.

My screen shows many messages that look like "cvs server: Invalid reply
from auth server (/srclist.txt) looking for ( /srclist.txt)".  But when I
look more closely (emacs hexl-mode on file produced by typescript), I see
that each occurrence of the file name is preceded by x'58 13 08'.  Some
other attempts produce error messages with other "funny" characters, and
still other attempts have no error messages at all.

I hate to suggest that there might be a bug in a the 1.11 branch of cvs,
but what could I have done to make this happen?

My cvs is 1.11.5, the precompiled binary that came with slackware 9.0,
which I installed recently.  So far as I know, I have used only standard
cvs--sometimes built from source--to maintain this sandbox, so I do not
think my hacked versions of cvs have had a chance to screw up *this*
sandbox.  Besides, I made this happen with a sandbox freshly checked out, too.

Transcript of session follows.  Thank you, all, for your attention.

Terry.

=== transcript of terminal session ==
Script started on Sun Aug  3 10:15:55 2003
[EMAIL PROTECTED]:~/ccvs$ cvs version
Client: Concurrent Versions System (CVS) 1.11.5 (client/server)
Server: Concurrent Versions System (CVS) 1.11.6 (client/server)
[EMAIL PROTECTED]:~/ccvs$ cat CVS/Root
:pserver:[EMAIL PROTECTED]:/cvs
[EMAIL PROTECTED]:~/ccvs$ cvs -z5 update
cvs server: Updating .
cvs server: Invalid reply from auth server (X/srclist.txt) looking for (
X/srclist.txt)
cvs server: Invalid reply from auth server (X/mktemp.sh) looking for (
X/mktemp.sh)
cvs server: Invalid reply from auth server (X/mkinstalldirs) looking for
( X/mkinstalldirs)
cvs server: Invalid reply from auth server (X/missing) looking for (
X/missing)
cvs server: Invalid reply from auth server (X/mdate-sh) looking for (
X/mdate-sh)
cvs server: Invalid reply from auth server (X/install-sh) looking for (
X/install-sh)
cvs server: Invalid reply from auth server (X/depcomp) looking for (
X/depcomp)
cvs server: Invalid reply from auth server (X/cvsnt.mak) looking for (
X/cvsnt.mak)
cvs server: Invalid reply from auth server (X/cvsnt.dsw) looking for (
X/cvsnt.dsw)
cvs server: Invalid reply from auth server (X/cvsnt.dsp) looking for (
X/cvsnt.dsp)
cvs server: Invalid reply from auth server (X/cvs.spec.in) looking for (
X/cvs.spec.in)
cvs server: Invalid reply from auth server (X/cvs-format.el) looking for
( X/cvs-format.el)
cvs server: Invalid reply from auth server (X/configure.in) looking for (
X/configure.in)
cvs server: Invalid reply from auth server (X/configure) looking for (
X/configure)
cvs server: Invalid reply from auth server (XHˆconfig.sub) looking for (
XHˆconfig.sub)
cvs server: Invalid reply from auth server (XHˆconfig.rpath) looking for
( XHˆconfig.rpath)
cvs server: Invalid reply from auth server (XHˆconfig.h.in) looking for (
XHˆconfig.h.in)
cvs server: Invalid reply from auth server (XHˆconfig.guess) looking for
( XHˆconfig.guess)
cvs server: Invalid reply from auth server (XHˆcompile) looking for (
XHˆcompile)
cvs server: Invalid reply from auth server (XHˆbuild.com) looking for (
XHˆbuild.com)
cvs server: Invalid reply from auth server (XHˆaclocal.m4) looking for (
XHˆaclocal.m4)
cvs server: Invalid reply from auth server (XHˆTODO) looking for (
XHˆTODO)
cvs server: Invalid reply from auth server (XHˆTESTS) looking for (
XHˆTESTS)
cvs server: Invalid reply from auth server (XHˆREADME.VMS) looking for (
XHˆREADME.VMS)
cvs server: Invalid reply from auth server (XHˆREADME) looking for (
XHˆREADME)
cvs server: Invalid reply from auth server (XHˆPROJECTS) looking for (
XHˆPROJECTS)
cvs server: Invalid reply from auth server (XHˆNEWS) looking for (
XHˆNEWS)
cvs server: Invalid reply from auth server (XHˆMakefile.in) looking for (
XHˆMakefile.in)
cvs server: Invalid reply from auth server (XHˆMakefile.am) looking for (
XHˆMakefile.am)
cvs server: Invalid reply from auth server (XHˆMINOR-BUGS) looking for (
XHˆMINOR-BUGS)
cvs server: Invalid reply from auth server (XHˆINSTALL) looking for (
XHˆINSTALL)
cvs server: Invalid reply from auth server (XHˆHACKING) looking for (
XHˆHACKING)
cvs server: Invalid reply from auth server (XHˆFAQ) looking for ( XHˆFAQ)
cvs server: Invalid reply from auth server (XHˆDEVEL-CVS) looking for (
XHˆDEVEL-CVS)
cvs server: Invalid reply from auth server (XHˆChangeLog.zoo) looking for
( XHˆChangeLog.zoo)
cvs server: Invalid reply from auth server (XHˆChangeLog) looking for (
XHˆChangeLog)
cvs server: Invalid reply from auth server (XHˆCOPYING.LIB) looking for (
XHˆCOPYING.LIB)
cvs server: Invalid reply from auth server (XHˆCOPYING) looking for (
XHˆCOPYING)
cvs server: Invalid reply from auth server (XHˆBUGS) looking for (
XHˆBUGS)
cvs server: Invalid rep

Re: Update versions

[Terrence Enger]

At 11:41 2003-07-10 -0400, Dewey M. Sasser wrote:
>"Giovanni Giazzon" <[EMAIL PROTECTED]> writes:
>
>> Yes, I'm a little confused about branches.

So was I, though I lacked the sense to realize it.

>
>Let me describe how I've used and seen branches.  That might help you
>out.
>

[substantive information snipped]

Thank you.  Seeing this expressed in one place helps a lot!

Terry.
Available for contract programming.





___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

how to add file to a module

[Terrence Enger]

Greetings.

I started with
  - a repository,
  - a module definition listing specific files,
  - a sandbox into which I have checked out that module.

Then, a vendor update (cvs import) adds a new file to the repository.  Upon
examination, I decide that the new file should be part of the module I am
talking about, and I update the modules file accordingly.  

What should I do to get a copy of that file in my sandbox?  Some
possibilities that come to mind ...
  - "cvs update" does not add the file.  Naturally, because my sandbox has
CVS/Entries.Static.
  - "cvs update -d" adds lots more files which are still not part of the
module. 
  - "cvs checkout filename" tells me "cvs server: cannot find module
`filename' - ignored"
  - From one level up in the directory tree, "cvs checkout
modulename/filename" tells me "cvs server: module `modulename/filename' is
a request for a file in a module which is not a directory.
  - Delete the sandbox and check out the module again.  I think this would
work, but I must not have any uncommitted changes.  

I fear that I am overlooking something very basic.

Thank you, all, for your help.

Terry.
iSeries programmer, available for contract programming.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: args to fchmod() and chmod()

[Terrence Enger]

At 11:10 2003-01-20 -0500, you wrote:
>Terrence Enger writes:
>> [snip]
>
>Are you certain that it's the file type bits that are causing the
>problem?  If so, I'd say that OS/400 is definitely *incorrect*.  The

When I tried fchmod() with each single bit set in the new mode, OS/400
returned an error for each value except S_IXOTH, S_IWOTH, S_IROTH, S_IXGRP,
S_IWGRP, S_IRGRP, S_IXUSR, S_IWUSR, S_IRUSR, S_ISGID, S_ISUID.  The file
type bits came to my attention first because they caused a failure during
sanity.sh.
>above-referenced specification says that chmod sets the SUID, SGID,
>sticky, and permission bits of the file to the "corresponding bits" in
>the argument.  There is no requirement that non-corresponding bits of
>the argument be set to any particular values.

Over the last several days, I have managed to read the specification both
ways.  (If I *really* cared, I suppose I would have to spend the ink to
print that page out .)

> [snip]

>
>As per the above spec, the valid bits are precisely:
>
>   (S_ISUID | S_ISGID | S_ISVTX | S_IRWXU | S_IRWXG | S_IRWXO)

Well, uh, yes.  But not all libraries define all these names.  I have
looked at all the stat.h which are readily available to me.  These are
OS/400 V5R1, Linux gcc 2.95.3, Mingw GCC 3.2, and Visual C++ 4.0; in each
case I used the default setup for compilation.  Only the Linux compiler
defines all these names.  OS/400 comes close, omitting only S_ISVTX.  The
two Windows compilers give names to the three "on" bits of octal 0700, but
have some disagreement about what the names should be.  (Sorry to seem
dense, I allowed myself to be intimidated by the many differences between
the platforms.  On cooler consideration, most of those differences do not
impact this task.)

Thank you for your help.

Terry.

>
>-Larry Jones
>
>Nobody knows how to pamper like a Mom. -- Calvin
>
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>
>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

args to fchmod() and chmod()

[Terrence Enger]

Greetings, all.

I notice that cvs in several places executes fchmod() or chmod(), and that
in some cases the new mode argument is the mode returned from an earlier
call to stat().  This value typically includes the file type.  

On most platforms this causes no problem, but OS/400 complains that "the
value specified for the argument is not correct".  Indeed, the
documentation of chmod() at
http://www.opengroup.org/onlinepubs/007908799/xsh/chmod.html lists the bits
which it can change and specifies that errno=EINVAL is a possible result,
so I think that OS/400 is arguably correct.

Does anybody forsee possible bad results from masking the mode argument
down to the valid bits?  Would the "official" cvs be willing to accept a
patch to this effect?

If this is a good idea, perhaps some expert can answer a couple of questions:
(*) Where should I define the valid bits?  Would anybody volunteer to help
me with the configuration tools?  Would anybody be willing to take over
that part of the work?
(*) sys/stat.h on different platforms define different subsets of the bits
named in the Posix specification.  In light experimentation on the
platforms I have readily available, I have not seen any unnamed bit affect
the value of the mode returned from stat().  How can I best define the
valid bits portably?

Thank you, all, for your attention.

Terry.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Bug tracking.

[Terrence Enger]

At 14:37 2002-10-11 -0500, Andrew Johnson wrote:
>J wrote:
>> 
>> Yes, but what I would like is a uniqe commit number, whatever it may be,
578
>> for instance applied to all the files involved in that single commit.
>
>That's just not how CVS works, and it never will.

Could you please tell us why think cvs will never have this feature?  If
you think it should never have this feature, I would like to hear about
that, too.

The feature would allow automatic recovery of some of the information which
developers--including the developers of cvs itself--maintain manually in
the files Changelog, so I do not see how it could be a *bad* thing to offer.

>
>However I believe Subversion uses this approach, go have a look at that. 
>If you're not willing to change the way you think/work to match the tool, 
>you'll have to change the tool instead.
>
>- Andrew
>-- 
>"Life is what happens while you're busy making other plans." - John Lennon
>
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>___
>Info-cvs mailing list
>[EMAIL PROTECTED]
>http://mail.gnu.org/mailman/listinfo/info-cvs
>
>



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

checkout.c uses strdup()

[Terrence Enger]

Greetings,

I notice that checkout.c, below the comment "/* strip the last_component
*/" still uses strdup() instead of xstrdup().  Is this an accedent?  FWIW,
OS/400 documents strdup() as an XPG4 extension.

Speaking of compiler warnings ... Does anybody still build cvs with a
compiler which does not accept function prototypes?

Thank you for your attention.
Terry

[Aside to moderator:  I tried to send this earlier from [EMAIL PROTECTED]
 Please discard that message.]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: What forum to propose new port?

[Terrence Enger]

At 12:00 PM 2002/03/11 -0500, you wrote:
>Terrence Enger writes:
>> 
>> (*) What does it mean?  Using an existing distribution of cvs
>> executing on Win95, I have had some success (very small test, no
>> observed problems) controlling ASCII source in the hierarchichal
>> part of the IFS of OS/400.  But I can see value in using cvs to
>> control a wider variety of stuff on the 400, ordered by what I
>> would deem to be descending value: source physical file members
>> (there are *lots* of those in the world), EBCDIC files, database
>> files.  Others with better imaginations than I can extend the
>> list.
>
>That looks like English, but I can't understand a word you said.

Uh-oh.  I'm gonna pack up my marbles and go back to coding .  But
first ...

>  I
>think you're going to have to educate us about the OS/400 environment
>before we can have an intelligent discussion.

Sad, but probably true.  Well, not sad for me, as I really like using
OS/400 and talking about it.  Stop me if I bore you too much.

OS/400 offers filesystems with a hierarchical directory structure.  Mostly,
people used to *nix or Windows would feel quite at home there.  In
particular, wherever you are in the hierarchy, cvs can create the cvs
subdirectoy that it wants to create.  The small successful test from my
original post involved simply mapping a directory in the hierarchical
directory structure to a network drive on the machine running cvs.

OS/400 also offers one widely used filesystem, "/QSYS.LIB", which is much
more restrictive in many ways.  Within this filesystem, source is stored in
"source physical file members".  These are at the lowest level of the name
space, and cvs cannot create a subdirectory as a sibling to these members.
No way, No Such Thing, It ain't gonna happen.

("IFS", which stands for Integrated File System, is a naming scheme which
can address all of these things.  However, it is the only naming scheme
offered which can address files outside the /QSYS.LIB filesytem, and people
quite often write IFS when they mean specifically the files which only IFS
can address.  Let me try that again...  People often write "IFS" when they
are talking about what I have called the "filesystems with a hierarchical
directory structure".)

I have tried to make cvs work by creating links in the hierarchical
directory structure to source physical file members.  Little success, but I
still think it *should* have worked.  Someday soon, I shall try again.

>  I feel obliged to note,
>however, that CVS was designed to version programming *source* files,
>not arbitrary files.  As is frequently discussed here, unless the files
>are divided into lines that can be meaningfully processed with something
>like the Unix 'diff' command, CVS really isn't a very effective tool.

Yes, I have noticed, and even contributed a bit to, that discussion.  I did
not want to limit discussion prematurely, but using cvs for OS/400 objects
other than source code is a question for another decade.

>
>> (*) How much of this change can the main line of development tolerate?
>> I note for example, your discussion "multiplatform sofware desing
>> problem" on bug-cvs with Dimitry Naldaev <[EMAIL PROTECTED]>, where
>> you take a position against having cvs do code conversions.  I can
>> imagine that much--but not all--of the necessary code would be
>> segreated into a platform-specific subdirectory.  
>
>CVS was really designed to work in an ASCII environment.  The only
>solution I can imagine for Dimitry's problem would be to rewrite CVS to
>use some universal character set (say, ISO 10646) internally (i.e., in
>the code, in the repository, in the client/server protocol, etc.) and
>convert between that and the system character set on I/O.  That would be
>an enourmous amount of work, I suspect it would be difficult to do it in
>an upward compatible form, it would probably make the repository files
>incompatible with RCS, it would significantly increase the size of most
>people's repositories, it would undoubtedly slow down CVS operations,
>and it would probably be a portability problem.
>
>Changing CVS to work in an EBCDIC-only enviroment should be much less
>work and have much less impact.  Even if you do have to interoperate
>between EBCDIC and ASCII, that shouldn't be too much more difficult
>since it is easy to define a useful, invertable mapping between ASCII
>and EBCDIC.  (Unfortunately, it is so easy that there are lots of them,
>which could present a problem if all your users can't agree on a single
>one.)

What part of cvs knows that it is working in ASCII?  So far, I have noticed
only a couple of pl

Re: What forum to propose new port?

[Terrence Enger]

At 03:39 PM 2002/03/09 -0500, Larry Jones <[EMAIL PROTECTED]> wrote:
>Terrence Enger writes:
>> 
>> Is this the best forum for proposing a port of cvs to OS/400 (a.k.a.
>> AS/400, a.k.a. iseries)?
>
>"Proposing" in what sense?  Are you proposing to do the work, or are you
>proposing that someone else do the work?  This is a good form for
>getting input from CVS users, [EMAIL PROTECTED] is a better forum for
>getting input from developers.
>
>-Larry Jones
>
[sig & list footer snipped]


Larry,

I propose, first of all, some questions.  

(*) What does it mean?  Using an existing distribution of cvs
executing on Win95, I have had some success (very small test, no
observed problems) controlling ASCII source in the hierarchichal
part of the IFS of OS/400.  But I can see value in using cvs to
control a wider variety of stuff on the 400, ordered by what I
would deem to be descending value: source physical file members
(there are *lots* of those in the world), EBCDIC files, database
files.  Others with better imaginations than I can extend the
list.

(*) How much of this change can the main line of development tolerate?
I note for example, your discussion "multiplatform sofware desing
problem" on bug-cvs with Dimitry Naldaev <[EMAIL PROTECTED]>, where
you take a position against having cvs do code conversions.  I can
imagine that much--but not all--of the necessary code would be
segreated into a platform-specific subdirectory.  

In my limited study of the code, I see platform-specific files
mapping one function to different facilities of the platform but
no example of one platform providing more functionality than
another.  Is there any case where you would like to exploit the
particular demands or capabilities of a particular platform?  Two
special cases could make a pattern; one special case would likely
just make a mess.

(*) What machines should execute what parts of cvs?  My own prejudice
favours allowing the programs to execute on OS/400, but other
arrangements are possible.  (You then might choose not to call it
a "port", of course.)

You ask whether I am proposing the work for myself to do or for
somebody else.  Let me answer with an absolute, definite "maybe".
Some subordinate points ...

(*) I have been hacking around on the 400 with the source from version
1.11.1p1.  It is clear to me that I have a lot to learn.  It is
*not* clear that I can learn what is required within the
limitations of my interest (which is itself subject to preemption
by paying customers, among other things).  My background includes
much work using OS/400, some work in C, but no previous work joining
the two areas.

(*) How much work are we looking at, and over what length of time?  So
far, each problem I hack around reveals more problems ahead of me.
Neither this or my (lack of) experience with ports like this gives
a basis for estimation.  I suspect that previous ports between
flavours of *nix might provide a poor lower bound on the effort
required.  The ports to Windows might give a better lower bound,
if I knew how much work they involved.  But cvs on Win95 omits
server functionality, and the developers of cvs on WinNT--if I
interpret the introductory web page correctly--have forked off
completely from the main line of cvs development.

I had a prejudice in favour of this proposed port when I started
writing, but I fail even to convince myself.  In short, I shall
probably continue hacking around while I feel I am learning something
and making a little "progress".  Whether this merits anyone else's
interest is debatable.

Any thoughts, Larry?  Anyone?

Terry.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

What forum to propose new port?

[Terrence Enger]

Greetings.

I solicit your opinions.

Is this the best forum for proposing a port of cvs to OS/400 (a.k.a.
AS/400, a.k.a. iseries)?

TIA,
Terry.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

XML diff and merge

[Terrence Enger]

Noel Yap <[EMAIL PROTECTED]> wrote, among lots more in a posting titled
"Re: CVS and Jar files: Should you import Jar into the Repository? Why or
why not" ...
quote --->
But if you think about it, a "correct" diff/merge for XML, Pascal, etc
would be a tree diff/merge, not a linear one.
<--- quote

IBM agrees; see ...
http://www.alphaworks.ibm.com/tech/xmltreediff


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs