Re: cvswrappers questions

2002-10-05 Thread Greg A. Woods

[ On Sunday, October 6, 2002 at 14:31:00 (+1000), Ken Williams wrote: ]
 Subject: Re: cvswrappers questions

 Now, I don't really expect that CVS is going to automatically 
 preserve filesystem attributes (in my case, they're type/creator 
 codes from an HFS+ filesystem, so it would perhaps have to do 
 something complicated to handle this natively - it's feasible 
 though, which I can explain in a separate message if someone's 
 interested), but I was looking for some way to manage the 
 process myself.

I think you missed the point.

CVS doesn't care about file attributes, beyond that they have to allow
the operations necessary for the invoking user to perform the various
operations CVS does.

CVS doesn't even care about directory structure.  Files simply exist in
a structure that CVS follows.  CVS, like RCS before it, only manages the
content of files, and only tracks changes to the content of, and the
presence or disappearance of, each file in that directory structure.

When you think about it that's really all you need to do to fulfil the
goals CVS was designed to fulfil -- CVS is a source code control system.

 Currently CVS does handle some filesystem attributes, like 
 permissions.

No, it doesn't at all.

(Well, there is the old and very broken-by-design carry-over from RCS of
preserving the execute permission by simply making the RCS file in the
repository executable  this is broken of course because there is no
versioning of this one bit of information -- it's all-or-nothing.  So
with respect to handling filesystem attributes, this isn't a valid
example -- just a cheap hack, as it is in RCS too.)

 Just trying to make it clear that the problem of 
 preserving filesystem meta-attributes is orthogonal to the 
 problem of text vs. binary contents, and one may be deemed worth 
 solving even if the other isn't.

CVS is not a build system.  If you wish to preserve meta-attributes of
files then you should write some program to set them as desired and then
maintain the source for that program using CVS.  That way you'll be
able to properly version control the changes to those attributes.

CVSwrappers was a really badly conceived and just about as badly
implemented idea to try to encase one or more files in an archive file
so that attributes could be preserved and versioned.  Unfortunately the
chosen archive format made it impossible to merge changes in those
files, at least using currently avaliable tools, and since merging is of
paramount importance to CVS, this was the first fatal flaw of
CVSwrappers -- it should have died on the drawing board.

-- 
Greg A. Woods

+1 416 218-0098;[EMAIL PROTECTED];   [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]


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



Re: cvswrappers questions

2002-10-04 Thread Ken Williams


On Thursday, October 3, 2002, at 01:23  AM, Frederic Brehm wrote:

 At 06:04 AM 10/2/2002, Ken Williams wrote:
 Original problem: I have a binary file that I'd like to store 
 in CVS.  It's a file used on Mac OS X, and needs to have 
 type/creator codes set properly in the filesystem.  These 
 codes don't survive a pass through the CVS repository (they 
 are empty when the file is checked out).

 Use your build system (make?) to fix the type/creator codes.

I'm not using a build system.  I'm just sharing project data.

This file is a database that the people working on this project 
need to access.  We each update it often, potentially, so we use 
'cvs watch on' and 'cvs edit' to manage concurrency.  In this 
way CVS is a good tool for sharing it, *except* for the fact 
that the file breaks every time we do updates.


 Second problem: now my CVSROOT/cvswrappers file is unusable 
 because of the above error, and I can't commit changes in 
 order to fix it - because of the same error.  How can I fix it 
 if I can't commit changes?

 When something like this happens to me, I resort to brute force 
 (a.k.a. CVS voodoo). Replace the file 
 $CVSROOT/CVSROOT/cvswrappers with the fixed version. Then 
 commit your changes. You'll need direct access to the 
 repository files to do this.

Darn, I suspected I might have to do this.  If I had the project 
on Sourceforge or someplace I didn't have direct access to the 
repository, I guess I'd be screwed.  Anyway, I'll give it a shot.

  -Ken



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



Re: cvswrappers questions

2002-10-04 Thread Frederic Brehm

At 08:13 PM 10/2/2002, Ken Williams wrote:
Use your build system (make?) to fix the type/creator codes.

I'm not using a build system.  I'm just sharing project data.

This file is a database that the people working on this project need to 
access.  We each update it often, potentially, so we use 'cvs watch on' 
and 'cvs edit' to manage concurrency.  In this way CVS is a good tool for 
sharing it, *except* for the fact that the file breaks every time we do 
updates.

How about making a simple two line script that performs the update and then 
fixes the type/creator codes? It shouldn't be hard to get other people on 
the project to use the script since it will make their life easier.

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/




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



Re: cvswrappers questions

2002-10-04 Thread Larry Jones

Ken Williams writes:
 
 I do feel like that's not a very good answer, though, since all 
 I'm claiming here is that certain types of files break just by 
 going into and out of CVS.  It seems like that might be 
 something worth fixing in CVS.

It is, it's just not very high priority.  -t/-f wrappers are useful for
a number of things, but they've been disabled for a long time now (and
they were broken for a long time before that) and no one has been
motivated to fix them, so they must not be very important.

-Larry Jones

Good gravy, whose side are you on?! -- Calvin


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



Re: cvswrappers questions

2002-10-04 Thread Eric Siegerman

On Fri, Oct 04, 2002 at 01:17:32PM -0400, Larry Jones wrote:
 Aborting a half-done commit is not something to be done lightly.

True!  Never mind...

--

|  | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
The acronym for the powers that be differs by only one letter
from that for the pointy-haired boss.


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



Re: cvswrappers questions

2002-10-03 Thread Frederic Brehm

At 06:04 AM 10/2/2002, Ken Williams wrote:
Original problem: I have a binary file that I'd like to store in 
CVS.  It's a file used on Mac OS X, and needs to have type/creator codes 
set properly in the filesystem.  These codes don't survive a pass through 
the CVS repository (they are empty when the file is checked out).

Use your build system (make?) to fix the type/creator codes.



Second problem: now my CVSROOT/cvswrappers file is unusable because of the 
above error, and I can't commit changes in order to fix it - because of 
the same error.  How can I fix it if I can't commit changes?

When something like this happens to me, I resort to brute force (a.k.a. CVS 
voodoo). Replace the file $CVSROOT/CVSROOT/cvswrappers with the fixed 
version. Then commit your changes. You'll need direct access to the 
repository files to do this.


Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/




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



Re: cvswrappers questions

2002-10-03 Thread Eric Siegerman

On Wed, Oct 02, 2002 at 08:04:30PM +1000, Ken Williams wrote:
 cvs [server aborted]: -t/-f wrappers not supported by this
 version of CVS.

The -t/-f functionality was removed quite some time ago.  If I
recall, it never worked well, and never worked at all
client/server.  If it's even documented, you must be using an
ancient CVS client (presumably the server is more recent, which
is why it fails).

I don't know how to make CVS do what you want.  I imagine people
will jump in and say that's not CVS's job; do it with your build
system :-/

 Second problem: now my CVSROOT/cvswrappers file is unusable 
 because of the above error, and I can't commit changes in order 
 to fix it - because of the same error.  How can I fix it if I 
 can't commit changes?

Hmm, not sure.  Fix it directly in the repo, I guess.  *shudder*
By which I do NOT mean to edit cvswrappers,v; but rather:
  - fix $CVSROOT/CVSROOT/cvswrappers
  - check out the CVSROOT module
  - fix sandbox/cvswrappers
  - commit
 
It'd be nice if CVS were more forgiving (i.e. if it reduced the
error to a warning if it was in an entry that's not triggered by
the current operation).

--

|  | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
The acronym for the powers that be differs by only one letter
from that for the pointy-haired boss.


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



Re: cvswrappers questions

2002-10-03 Thread Larry Jones

Ken Williams writes:
 
 Second problem: now my CVSROOT/cvswrappers file is unusable 
 because of the above error, and I can't commit changes in order 
 to fix it - because of the same error.  How can I fix it if I 
 can't commit changes?

I'm afraid you have to edit the repository file directly.

-Larry Jones

Bad news, Mom.  I promised my soul to the Devil this afternoon. -- Calvin


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



Re: cvswrappers questions

2002-10-03 Thread Larry Jones

Eric Siegerman writes:
  
 It'd be nice if CVS were more forgiving (i.e. if it reduced the
 error to a warning if it was in an entry that's not triggered by
 the current operation).

Unfortunately, at the time the error is detected, CVS has no idea
whether that particular entry is going to end up being used or not.

-Larry Jones

These things just seem to happen. -- Calvin


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



Re: cvswrappers questions

2002-10-03 Thread Ken Williams


On Friday, October 4, 2002, at 12:32  AM, Frederic Brehm wrote:

 At 08:13 PM 10/2/2002, Ken Williams wrote:
 Use your build system (make?) to fix the type/creator codes.

 I'm not using a build system.  I'm just sharing project data.

 This file is a database that the people working on this 
 project need to access.  We each update it often, potentially, 
 so we use 'cvs watch on' and 'cvs edit' to manage 
 concurrency.  In this way CVS is a good tool for sharing it, 
 *except* for the fact that the file breaks every time we do 
 updates.

 How about making a simple two line script that performs the 
 update and then fixes the type/creator codes? It shouldn't be 
 hard to get other people on the project to use the script since 
 it will make their life easier.


That doesn't really work.  This is part of a larger repository.  
The nature of using CVS is that you don't know in advance when 
any particular file in the repository has changed - you just 
type 'cvs update' and get the changes on all files distributed 
to you.  So in order for your idea to work, people would have to 
use the new script/alias when doing updates from any place in 
the working directory that could possibly update this file.

Anyway, the practical hurdles here have been too great, I think 
I'm giving up on it.

  -Ken



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



Re: cvswrappers questions

2002-10-03 Thread Ken Williams


On Thursday, October 3, 2002, at 01:33  AM, Eric Siegerman wrote:

 On Wed, Oct 02, 2002 at 08:04:30PM +1000, Ken Williams wrote:
 cvs [server aborted]: -t/-f wrappers not supported by this
 version of CVS.

 The -t/-f functionality was removed quite some time ago.  If I
 recall, it never worked well, and never worked at all
 client/server.  If it's even documented, you must be using an
 ancient CVS client (presumably the server is more recent, which
 is why it fails).

The client is:

   Concurrent Versions System (CVS) 1.10 `Halibut' (client/server)

which is the version distributed with OS X 10.1.

The server is:

   Concurrent Versions System (CVS) 1.10.8 (client/server)

 I don't know how to make CVS do what you want.  I imagine people
 will jump in and say that's not CVS's job; do it with your build
 system :-/

Yeah, that's what people have said.

I do feel like that's not a very good answer, though, since all 
I'm claiming here is that certain types of files break just by 
going into and out of CVS.  It seems like that might be 
something worth fixing in CVS.

 Second problem: now my CVSROOT/cvswrappers file is unusable
 because of the above error, and I can't commit changes in order
 to fix it - because of the same error.  How can I fix it if I
 can't commit changes?

 Hmm, not sure.  Fix it directly in the repo, I guess.  *shudder*
 By which I do NOT mean to edit cvswrappers,v; but rather:
   - fix $CVSROOT/CVSROOT/cvswrappers
   - check out the CVSROOT module
   - fix sandbox/cvswrappers
   - commit

Thanks, that seems to have worked.

  -Ken



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