Re: cvswrappers questions
[ 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
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
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
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
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
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
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
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
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
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
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