[Top][All Lists]

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

Re: HELP! Howto disable binary flags on files

From: Eric Siegerman
Subject: Re: HELP! Howto disable binary flags on files
Date: Wed, 12 Sep 2001 14:45:49 -0400
User-agent: Mutt/1.2.5i

What I'm about to say applies to older versions of CVS, at least
up to 1.10.8.  The latest version of CVS, 1.11.1p1, behaves
better; I'll get to that at the end.  Whether these comments
apply to jCVS will depend on which version of the original CVS it
was modelled on, and, if an old one, whether it has picked up
recent improvements.

On Wed, Sep 12, 2001 at 12:12:32PM +0200, Marko Faldix wrote:
> "Josh Baudhuin" <address@hidden> schrieb im Newsbeitrag
> news:address@hidden
> > cvs admin -kkv <not-really-binary-file>
> where do you type in the cvs admin commands. As user on clients? I tried in
> unix command line in the repository directory on the server, but there was
> no file "entries" found, which normally resides on the client after
> checkout. But on the client, we have NT 4.0 with jCVS an the cvs admin
> command did not change anything. So where is the command line for this
> commands?

Yes, you type "cvs admin" in a CVS working directory (aka
sandbox).  But it doesn't modify the sandbox, only the repository
(it's kind of ugly that way); so, having done the "cvs admin",
you have to fix the sandbox yourself.

The easiest way, for a global change like yours, is probably to
have all the users delete their sandboxes and check out new ones.
Be careful to back up any uncommitted changes first, of course!
Before doing all that, you might want to verify that the "cvs
admin" really did modify the repository, by doing a "cvs log" (or
the jCVS equivalent), and checking that the values reported for
"keyword substitution" are now correct.

Why does "cvs admin" not modify the sandbox?  Because it was
intended as a "back door", to let you do things at the RCS level
that CVS doesn't understand.  It's a *very* thin layer over the
"rcs" command -- all it does, I think, is to map the sandbox
pathnames to the corresponding ,v files, and provide CVS's
standard recursive and client/server features.  You can see this
history in the fact that the "cvs admin" subcommand has a synonym
"rcs", and also hinted at by this quote from the manual:
      This is the CVS interface to assorted administrative facilities.
      Some of them have questionable usefulness for CVS but exist for
      historical purposes.  Some of the questionable options are likely to
      disappear in the future.

Like earlier versions, CVS 1.11.1p1 does not update the sandbox
when you use "cvs admin -k".  However, a subsequent "cvs update"
will notice that the sandbox needs updating, and do so.  In this
version, it's sufficient to go:
        cvs admin -k<whatever> file1 file2 dir3
        # more "cvs admin" commands
        cvs update

In 1.10.8, and presumably jCVS, "cvs update" does NOT notice the
discrepancy, and does NOT make any attempt to fix it.  Hence the
need to fix it yourself.

Another possibility in your case is to try WinCVS instead of
jCVS, for this one operation even if you don't switch to it
permanently.  It's not a reimplementation as jCVS is; it's a GUI
layer built on the original command-line CVS.  The latest WinCVS
version, 1.2, is layered on CVS 1.11, which might be recent
enough to have the improvements I've described.

Good luck!


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

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