Re: Spaces added ... and line endings in general
On Tue, Jan 23, 2001 at 06:40:19PM -0500, Laine Stump wrote: > > Strikes me this might actualy make the CVS code simpler :-) ... instead > > of converting to local conventions (thus needing too know what they > > are) you would simply pass the cannonical file through a filter which > > 'localised' it as requested. > > Right now CVS is relying on the C library file functions (fopen, > fputs, etc) to do the "filtering". Yup; the CVS code is already as simple as it could possibly be: open the working file with or without a "b" in the fopen() mode string, and let stdio handle it from there. > [...] the only tool I > use that doesn't accept/deal with multiple line-end conventions is _CVS > itself_. Your other tools deal with two line-end conventions, maybe three (ie. Mac), if you're really lucky. It doesn't deal with *all* relevent conventions. CVS does, by definition (where the definition of "relevent" is "CVS has been ported to it"). Automatically (see above). As long as you don't try to fool it. How should a *single* CVS executable "accept/deal with" all of the following, which it *must* do if it's to defend itself against the kinds of abuse you want to throw at it? - Unix format: - DOS format: - Mac format: - Files in which some lines use one of the above conventions, and some use another (because you edited a DOS-format file in vi on a Unix box, and didn't religiously type the ^v^m's) - Unix-format files that contain s as actual formatting characters -- perhaps even at the ends of lines, for doing overstriking, so looking specifically for is unsafe - Record-oriented formats which use length words and have no terminator at all. This is old mainframe stuff -- dying, but alas not dead yet. (For an example, see below.) > > But it would need to be set in variety of ways: > > > > setting on file, > > overridden by .rc file, > > overridden by environment, > > overridden by cmd options > > YES This is exactly what I'd like to see! (naysayers be damned! ;-) Perhaps I'm being obtuse, but how does this help with the following use case: > The only problem is when you do the checkout on platform X, > then work with that work directory on platform Y. Semi-aside: here's an example of a record-oriented format, for those who've never been, ahem, lucky enough to work on a system that uses one. This is (as nearly as I can recall; it's been a *long* time), the text-file format used by VMS. Each text line consists of a "short" containing the record length, in binary, followed by that many bytes of ASCII, padded to a word boundary. Here's what my favourite Ogden Nash poem would look like in the format I've described (which may or may not be exactly VMS's). Notice the blank line between heading and body: 0008546865204c616d61000d6279204f . .T he L am a. .b y O 6764656e204e61736800001a4120 g de n Na sh .. .. .A 6f6e652d4c206c616d61206865277320 o ne -L l am a he 's 6120707269657374001a412074776f2d a p ri es t. .A t wo - 4c206c6c616d61206865277320612062 L l la ma h e' s a b 65617374001d416e64204920776f756c e as t. .A nd I w ou l 642062657420612073696c6b2070616a d b et a s il k pa j 616d6100001e54686572652069736e27 a ma .. .T he re i sn ' 7420616e792074687265652d4c206c6c t a ny t hr ee -L l l 6c616d61 l am a Here's the cleartext: The Lama by Ogden Nash A one-L lama he's a priest A two-L llama he's a beast And I would bet a silk pajama There isn't any three-L lllama -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / 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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
TortoiseCVS Manual?
Is it just me, or is http://www.wincvs.org down? I am new to CVS. Last week I downloaded and installed the Tortoise CVS utility. It seems to fit my needs pretty well, but I really need to read a bit more about connecting W2k clients to a UNIX-based repository. But I can't get to the site to read the Tortoise CVS or WinCVS manuals! Doh! Is there anyone on the list who can send me the docs that I need? On another note, does anyone here use CVS to control hardware design source files? Ya know, Verilog, VHDL, schematics, etc. I'd love to speak to someone who controls PCB designs with CVS... Marshall Wood HW Tools Engineer WaterCove Networks [EMAIL PROTECTED] 978-608-2123 voice 978-256-9852 fax ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Remote CVS and CVSROOT/editinfo scripts requiring tty input
Hey, I have scripts specified from CVSROOT/editinfo that require user input during a commit (the perl script does something like "$answer = "). These scripts work fine using local CVS. However, when I use remote CVS (using ssh), the scripts do not prompt the user for info. Is there a way to get CVS to get my scripts to work correctly (ie ask the user for input) when using CVS remotely? Thanks, --Mike - Mike McKay [EMAIL PROTECTED] 505-665-2714 - ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Spaces added ... and line endings in general
[EMAIL PROTECTED] writes: > LS> I agree. This makes sense to me, and would make my life *much* easier. > LS> IF AND ONLY IF CVS also simultaneously gained the extra intelligence > LS> to determine the original (checkout time) line-ending convention of > LS> each *workfile*, and preserve that through subsequent operations. > > > You can (kind-of) do that today with the -kb option (set via WRAPPERS) But that has other unwanted side effects (doesn't it disable keyword substitution?), and only has the effect of removing *all* line-end conversion. > However what would be REALLY useful would be: > > Can set MODE of a file to (say) DOS, UNIX, MAC ... others > > (personally I don't need this as all the tools I use accept all conventions > :-) Mine too *kind of*. Unfortunately, I occasionally make the mistake of adding a line using MS Visual Studio (only during debugging when I forget to switch to Emacs!), and it puts a CRLF-terminated line in the middle of an all-newline file. Bah! Other than that, the only tool I use that doesn't accept/deal with multiple line-end conventions is _CVS itself_. > But it would need to be set in variety of ways: > > setting on file, > overridden by .rc file, > overridden by environment, > overridden by cmd options YES This is exactly what I'd like to see! (naysayers be damned! ;-) > Why all this complexity? Consider: > > I'm on DOS but I want to edit a shell script run on the PSERVER on Unix > > I'm a web server/cron-job and I'm doing this checkout on the Unix box, > so that > an overnight build running on a MS-DOS pc can make the binaries U-2-D. > > I'm using a MAC to checkout files to add some comments for my group > who use MS-DOS pc to develop code :-) Well, most of those cases already "just work". The only problem is when you do the checkout on platform X, then work with that work directory on platform Y. I actually end up doing that a lot, often unintentionally, because I develop code that runs on both Windows and Unix, and happen to prefer doing everything except compilation on Unix. > Strikes me this might actualy make the CVS code simpler :-) ... instead > of converting to local conventions (thus needing too know what they > are) you would simply pass the cannonical file through a filter which > 'localised' it as requested. Right now CVS is relying on the C library file functions (fopen, fputs, etc) to do the "filtering". ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit problem
Alain Fontaine writes: > > Checking in system.class.inc; > c:\cvs/Assurances/Classes/system.class.inc,v <-- system.class.inc > cvs [commit aborted]: end of file from server (consult above messages if > any) Sounds like the server's crashing. I suggest trying the same thing on the server machine accessing the repository in local mode to see if you can get any more information about what's going wrong. -Larry Jones What's Santa's definition? How good do you have to be to qualify as good? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Recommended Layout? [Ooops, Sorry]
Ah, I'm sorry as I can be ... reading the FAQ's properly has answered my question. (Put it all in one repository.) > We're installing CVS to manage multiple (dozens of projects). At > present each project has its own directory tree including a > subdirectory for source files. > > With CVS, which of the following do you think is a better layout? > > 1. A single repository containing directories from all projects. > 2. A separate CVS repository for each and every project. > > Many thanks, > Ayyaz ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Recommended Layout?
We're installing CVS to manage multiple (dozens of projects). At present each project has its own directory tree including a subdirectory for source files. With CVS, which of the following do you think is a better layout? 1. A single repository containing directories from all projects. 2. A separate CVS repository for each and every project. Many thanks, Ayyaz ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Commit problem
Hi, When I do a commit on a particular file, I get this error response from my CVS server: <-- snip --> Checking in system.class.inc; c:\cvs/Assurances/Classes/system.class.inc,v <-- system.class.inc cvs [commit aborted]: end of file from server (consult above messages if any) <-- snip --> This happens when I checkout the module, edit that file, and then try to commit. I do not have this problem with any other of the 100+ files, though, just this one. Setup: Client WinCVS 1.17b, server: CVS-NT. Any ideas greatly appreciated. Thanks ! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: MT response and update -p command
Milos Kleint writes [quoting me]: > > > > This is historical. Before CVS had the MT response, that is exactly > > what happened to a final partial output line -- it was discarded. > > So the MT response is the fix to the the bug? :) You could say that. Although as I recall, the MT response was really invented for a bunch of other reasons, it just so happened that it provided an easy fix for this problem, too. > Well, the 5.14 chapter says no word about MT being required. It's not. In general, if a client or server doesn't implement a required command or response, other clients and servers won't be able to talk to it at all. If you don't implement MT, servers are perfectly happy to talk to you and everything even works right except for this one very rare case that gives you less than desirable results. > That's why we > decided not to implement, because we didn't find the 5.12 chapter quite > clear and detailed and we thought that we can start with only M and E > responses and that we can add MT later. What isn't clear? A simple minimal implementation is to completely ignore tags that start with + or -, to print a newline for the newline tag, and to print the following text for any other tags. -Larry Jones I've never seen a sled catch fire before. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
>> I don't think so. You have to be owner (or root) to change the permissions. > >Well, that seems a little silly as the following makes you the owner if you have >write permissions to the directory: > >#! /bin/sh >cat afile,v >afile,v.new >mv afile,v.new afile,v If you peek under the hood, the new afile,v isn't the same file as the old afile,v (ie they have different inodes). Looking at it a different way, it makes sense 'cos when you're copying and moving files, you're really changing (ie writing) the directory. We actually take advantage of this feature to coordinate our work. We set our umasks to 027 making files group read-only. It is now impossible to write over accidentally someone else's file (eg, an installed jar file). Ideally we would contact the owner of the file to see if they're still working on it. If they're not working on it, or if they can't be contacted, we move the file out of the way, and create our own. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
FW: Spaces added ... and line endings in general
-Original Message- From: Graeme Vetterlein Sent: Tuesday, January 23, 2001 5:40 PM To: [EMAIL PROTECTED] Subject: RE: Spaces added ... and line endings in general -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... lots of mess caused by gnu.org checking my From: line (a SUN behind a firewall) and Emacs insisting on setting my From: to the real machine I'm sending from (yes I know I should set up site hiding, but since even the userids differ ... oh well) Sent: Tuesday, January 23, 2001 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Spaces added ... and line endings in general DP> What is stopping us from writing the db files natively from whatever DP> platform but allowing any of the three line endings when reading DP> them in? LS> LS> (By "db files" you mean CVS/Entries, CVS/Root, and CVS/Repository, LS> right?) I hope so. LS> I agree. This makes sense to me, and would make my life *much* easier. LS> IF AND ONLY IF CVS also simultaneously gained the extra intelligence LS> to determine the original (checkout time) line-ending convention of LS> each *workfile*, and preserve that through subsequent operations. You can (kind-of) do that today with the -kb option (set via WRAPPERS) However what would be REALLY useful would be: Can set MODE of a file to (say) DOS, UNIX, MAC ... others (personally I don't need this as all the tools I use accept all conventions :-) But it would need to be set in variety of ways: setting on file, overridden by .rc file, overridden by environment, overridden by cmd options Why all this complexity? Consider: I'm on DOS but I want to edit a shell script run on the PSERVER on Unix I'm a web server/cron-job and I'm doing this checkout on the Unix box, so that an overnight build running on a MS-DOS pc can make the binaries U-2-D. I'm using a MAC to checkout files to add some comments for my group who use MS-DOS pc to develop code :-) Strikes me this might actualy make the CVS code simpler :-) ... instead of converting to local conventions (thus needing too know what they are) you would simply pass the cannonical file through a filter which 'localised' it as requested. -- It's no surprise that things are so screwed up: everyone that knows how to run a government is either driving taxicabs or cutting hair. -- George Burns Graeme ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Spaces added ... and line endings in general
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... lots of mess caused by gnu.org checking my From: line (a SUN behind a firewall) and Emacs insisting on setting my From: to the real machine I'm sending from (yes I know I should set up site hiding, but since even the userids differ ... oh well) Sent: Tuesday, January 23, 2001 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Spaces added ... and line endings in general DP> What is stopping us from writing the db files natively from whatever DP> platform but allowing any of the three line endings when reading DP> them in? LS> LS> (By "db files" you mean CVS/Entries, CVS/Root, and CVS/Repository, LS> right?) I hope so. LS> I agree. This makes sense to me, and would make my life *much* easier. LS> IF AND ONLY IF CVS also simultaneously gained the extra intelligence LS> to determine the original (checkout time) line-ending convention of LS> each *workfile*, and preserve that through subsequent operations. You can (kind-of) do that today with the -kb option (set via WRAPPERS) However what would be REALLY useful would be: Can set MODE of a file to (say) DOS, UNIX, MAC ... others (personally I don't need this as all the tools I use accept all conventions :-) But it would need to be set in variety of ways: setting on file, overridden by .rc file, overridden by environment, overridden by cmd options Why all this complexity? Consider: I'm on DOS but I want to edit a shell script run on the PSERVER on Unix I'm a web server/cron-job and I'm doing this checkout on the Unix box, so that an overnight build running on a MS-DOS pc can make the binaries U-2-D. I'm using a MAC to checkout files to add some comments for my group who use MS-DOS pc to develop code :-) Strikes me this might actualy make the CVS code simpler :-) ... instead of converting to local conventions (thus needing too know what they are) you would simply pass the cannonical file through a filter which 'localised' it as requested. -- It's no surprise that things are so screwed up: everyone that knows how to run a government is either driving taxicabs or cutting hair. -- George Burns Graeme ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: MT response and update -p command
> > Milos Kleint writes: > > > > It actually works fine all the time, except one case. when > doing update -p > > or checkout -p > > If the file doesn't end with a new-line, then the final > line of the source > > is discarded. While debugging this behaviour and by comparing our > > client-server communication and the cvs.exe one, I realized > the the final > > line is sent (as opposed to the rest of the file) with the > MT response. > > And because we don't support it, the server decided to send > nothing to us. > > This is historical. Before CVS had the MT response, that is exactly > what happened to a final partial output line -- it was discarded. So the MT response is the fix to the the bug? :) > > > I'm aware of the fact that it "hack" is used to set the > right new-lining to > > the file being sent however IMHO it should at least send the wrong M > > response. > > I'm inclined to agree -- anyone want to argue against such a change? > > > Is this really a bug or do we have to support the MT > response? Where to fill > > this bug? Is there any list of required responses and > requests? I couldn't > > find anything like that in the Cvs client/server document.. > Is there a more > > in-depth description of the MT response somewhere? > > The MT response is the only way the protocol has to support a partial > line; if you want your clients to support partial lines, then you'll > have to support MT. It's described in detail in 5.11 and 5.12 of the > CVS Client/Server document; required commands and responses are > discussed in 5.14. Bug reports (as per HACKING) go to > [EMAIL PROTECTED] > Well, the 5.14 chapter says no word about MT being required. That's why we decided not to implement, because we didn't find the 5.12 chapter quite clear and detailed and we thought that we can start with only M and E responses and that we can add MT later. So if MT is actually required, that should be added to the document. Milos Kleint ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tags in keyword substitutions
I should point out that $Name$ only works if you checkout or export based on a tag. But, this is the only way you should be building release candidates anyway. Rex. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Converting binary files to text
This one, and Eugene's ideas are both good. Thanks for the ideas! - Dennis - Original Message - From: "Larry Jones" <[EMAIL PROTECTED]> To: "Dennis Jones" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 23, 2001 7:42 AM Subject: Re: Converting binary files to text > Dennis Jones writes: > > > > rm filename.ext # remove the binary file > > cvs rm filename.ext # remove the file from the repository > > cvs ci filename.ext # commit the remove > > > > remove the original file from the Attic > > > > cvs ad filename.ext # add the new text file > > cvs ci filename.ext # commit the add > > > > At this point, the repository is correct, and a 'cvs up -A' by the user gets > > him the correct file in his local trees. It's a little convoluted, but it > > seems to work. > > If you're going to remove the repository file, there's no point in cvs > removing it first. Since the users are going to have to do update -A > anyway, I think I'd prefer just using cvs admin -kkv to remove the > binaryness from the existing repository file, update -A your working > directory, and then check in the new text file. That way, you don't > lose your existing revision history. > > -Larry Jones > > I don't see why some people even HAVE cars. -- 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
Re: Setting up remote access
"Furmaniuk, Michael" wrote: > I've built and moved the crypto.h file created when I built the OpenSSL > package, but still get stopped when I am doing make for CVSI get to this > point and am not sure why. > > -L/usr/local/include/gssapi/lib -lgssapi_krb5 -lkrb5 -lcrypto -lcom_err -o > cvs > ld: fatal: library -lcrypto: not found > ld: fatal: File processing errors. No output written to cvs > *** Error code 1 The libcrypto.a file needs to be somewhere in your library path. Mine's in /usr/lib . A full install of OpenSSL should do the trick, but if you don't want to do that you may be able to just copy libcrypto.a and any appropriate header files into usuable locations before you compile. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not instigate revolution. I will not instigate revolution. I will not instigate revolution... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Beginner question
Hi group, We wan´t start to use CVS as a repository to our source-codes, but I don´t know what is the best client for accessing from windows stations (the wincvs.org appear to be down) nor the procedures at the server to configure access from a windows client. Can someone give me a light on it? Thanks, Leonardo _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tags in keyword substituions ??
"Derek R. Price" wrote: > Peter Biechele wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > I sthere a way to put the newest Tag of each file into the files by using > > keyword substitutions ?? > > Not according to my manual. Whoops. $Name$. From: http://cvshome.org/docs/manual/cvs_12.html#SEC99 . Thanks to [EMAIL PROTECTED] . Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not sell land in Florida. I will not sell land in Florida. I will not sell land in Florida... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: MT response and update -p command
Milos Kleint writes: > > It actually works fine all the time, except one case. when doing update -p > or checkout -p > If the file doesn't end with a new-line, then the final line of the source > is discarded. While debugging this behaviour and by comparing our > client-server communication and the cvs.exe one, I realized the the final > line is sent (as opposed to the rest of the file) with the MT response. > And because we don't support it, the server decided to send nothing to us. This is historical. Before CVS had the MT response, that is exactly what happened to a final partial output line -- it was discarded. > I'm aware of the fact that it "hack" is used to set the right new-lining to > the file being sent however IMHO it should at least send the wrong M > response. I'm inclined to agree -- anyone want to argue against such a change? > Is this really a bug or do we have to support the MT response? Where to fill > this bug? Is there any list of required responses and requests? I couldn't > find anything like that in the Cvs client/server document.. Is there a more > in-depth description of the MT response somewhere? The MT response is the only way the protocol has to support a partial line; if you want your clients to support partial lines, then you'll have to support MT. It's described in detail in 5.11 and 5.12 of the CVS Client/Server document; required commands and responses are discussed in 5.14. Bug reports (as per HACKING) go to [EMAIL PROTECTED] -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
Larry Jones wrote: > Derek R. Price writes: > > > > cat afile,v >afile,v.new > > You have something against the cp command? :-) Well, I did initially. By default it preserves permissions on my system. I guess it shouldn't really matter in the above case since Robert was going to have to chmod a-w anyhow. I just stopped thinking about that somewhere along the line as I was playing around and saw the execute bits go away. Besides, who else uses cat. It makes me look unique. ;) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- We shall have our follies without doubt. Some one or more of them will always be afloat. But ours will be the follies of enthusiasm, not of bigotry, not of Jesuitism. Bigotry is the disease of ignorance, of morbid minds; enthusiasm of the free and buoyant. Education and free discussion are the antidotes of both. We are destined to be a barrier against the return of ignorance and barbarism. - Thomas Jefferson to John Adams, 1816 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
On Tue, Jan 23, 2001 at 09:06:01AM -0500, Noel L Yap wrote: > You can: >cd $CVSROOT/module_dir >cp -p archive,v archive,v~ >mv -f archive,v~ archive And make sure that archive,v is not modified via cvs between the cp and the mv command. Ingolf -- Ingolf SteinbachBalin@IRCnet ICQ#60829470 PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removed a file, now cannot add it back...
Eric Sommerlade writes: > > I still wonder how this can happen - I suspected a crazy developer (with > nfs access to the cvs tree, too) here, but now I read that this can > happen with client/server cvs (as on sourceforge), too. > is it a bug or a feature? If CVS doesn't move the repository file into the Attic when it's deleted from the trunk, it's a bug unless it also produces some kind of error message indicating that something went wrong. -Larry Jones I don't think math is a science, I think it's a religion. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
On Tue, Jan 23, 2001 at 10:30:33AM -0500, Derek R. Price wrote: > > I don't think so. You have to be owner (or root) to change the permissions. > > Well, that seems a little silly as the following makes you the owner if you have > write permissions to the directory: But this is what is enforced by various Unix / Unix-like systems. Regards Ingolf -- Ingolf SteinbachBalin@IRCnet ICQ#60829470 PGP: 0x7B3B5661 213C 828E 0C92 16B5 05D0 4D5B A324 EC04 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Removed a file, now cannot add it back...
Hola chicas, we had the same problem here. In our case, the RCS file of the file in question was not placed in the Attic directory (as the error message correctly states), but the state of the file is 'dead', anyway. So, when trying to restore the file via adding or update -j r1 -j r2, cvs complains about the still 'living' file, since the RCS file is not in the Attic. The only solution I know is moving the file back into the Attic. Unfortunately you need direct access to the server, then. I still wonder how this can happen - I suspected a crazy developer (with nfs access to the cvs tree, too) here, but now I read that this can happen with client/server cvs (as on sourceforge), too. is it a bug or a feature? cheers, eric Ferdinando Ametrano wrote: > > >Several months ago we removed a file from the CVS tree, and now we are > >trying to check a file with the same name back in again. > > [omissis] > Since I do not have access to the SourceForge CVS I had to ask SourceForge > support for their help. > They solved the problem, but I'm not sure how. > That's all I know. > > Any additional info is welcome, since I run once again into the same > problem, so I guess there must be something more (e.g. problem with > lowercase/uppercase file name using WinCVS client and Unix CVS server) > > ciao -- Nando > > ___ > 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
Re: Converting binary files to text
Dennis Jones writes: > > rm filename.ext # remove the binary file > cvs rm filename.ext # remove the file from the repository > cvs ci filename.ext # commit the remove > > remove the original file from the Attic > > cvs ad filename.ext # add the new text file > cvs ci filename.ext # commit the add > > At this point, the repository is correct, and a 'cvs up -A' by the user gets > him the correct file in his local trees. It's a little convoluted, but it > seems to work. If you're going to remove the repository file, there's no point in cvs removing it first. Since the users are going to have to do update -A anyway, I think I'd prefer just using cvs admin -kkv to remove the binaryness from the existing repository file, update -A your working directory, and then check in the new text file. That way, you don't lose your existing revision history. -Larry Jones I don't see why some people even HAVE cars. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
Robert-Jan Elias wrote: > "Derek R. Price" wrote: > > > [EMAIL PROTECTED] wrote: > > > > > 1) If you check in sources with wrong permissions (for example you > > > forgot to set x-permissions) you have to manually chmod the file under > > > /var/cvs. But because the file is owned by the last changer, you > > > cannot do this from the webtool. Are there any other ways (through CVS > > > commands) to change permissions of existing CVS resources. > > > > Don't knw what webtool you're using, but any developer with write access > > to the file should be able to change the perms. > > > > I don't think so. You have to be owner (or root) to change the permissions. Well, that seems a little silly as the following makes you the owner if you have write permissions to the directory: #! /bin/sh cat afile,v >afile,v.new mv afile,v.new afile,v > > > 2) We export CVS sources to a directory for internal testing and other [. . .] > > Nope. You should be able to script something using co/update instead of > > export and accessing the admin files (preferrably through cvs status or > > the like), though. > > > > We are using 'update' for placing stuff in the test environment at the moment, but > we do not like this because people might be adding print statements to this code > for debug purposes. When updating you can get conflicts because of this. Therefore > we would like an exported project where people can try out stuff, but without the > possibility of this stuff ending up under CVS. If you save the version tag, something like (and I doubt this is exact syntax) 'cvs rdiff --brief -D"beginning of time" -rexportversion module' should report a list of files for you. > > > 3) Does anybody have experience with the combination of CVS and [. . .] > > If you can export the database structure in a text format, it's easy. [. . .] > Thanks, I think that is a very good suggestion! You're welcome. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- To err is human, to moo bovine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Setting up remote access
>> Thanks for the assist on this, but I am still having problems compiling. >> I got the Kerberos distribution from MIT and built it thinking that I'd find >> a crypto library in the build but I'm not seeing it. This is my first time >> building CVS, so maybe I need to get a "crypto" library from somewhere else? >> >> When I build CVS I get partway through the make and get the following >> error line: >> >> library -lcrypto: not found >> >> Anyone know where I can find this? > >Mine was apparently installed with OpenSSL 0.9.6. Not sure how CVS is using >this. I've built and moved the crypto.h file created when I built the OpenSSL package, but still get stopped when I am doing make for CVSI get to this point and am not sure why. -L/usr/local/include/gssapi/lib -lgssapi_krb5 -lkrb5 -lcrypto -lcom_err -o cvs ld: fatal: library -lcrypto: not found ld: fatal: File processing errors. No output written to cvs *** Error code 1 I made a lib directory under gssapi and put all but the cvs file in there, wasn't sure if I should but thought it might help, and still it fails in building. Am I missing something else? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS/Entries.Log
Manish Koolwal wrote: > cvs [update aborted]: cannot open CVS/Entries.Log: Permission denied > > The problem is that I could not see any Entries.Log file anywhere. Now > even when I run cvs status, there is same error message. You need write permissions to the local ./CVS directories. There should be one in each of your workspace directories. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Life in a vacuum sucks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tags in keyword substituions ??
Peter Biechele wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I sthere a way to put the newest Tag of each file into the files by using > keyword substitutions ?? Not according to my manual. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Life in a vacuum sucks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
>1) If you check in sources with wrong permissions (for example you >forgot to set x-permissions) you have to manually chmod the file under >/var/cvs. But because the file is owned by the last changer, you >cannot do this from the webtool. Are there any other ways (through CVS >commands) to change permissions of existing CVS resources. You can: cd $CVSROOT/module_dir cp -p archive,v archive,v~ mv -f archive,v~ archive >2) We export CVS sources to a directory for internal testing and other >non-CVS content might be added in this stage. At some time we want to >export the newest release to the test environment, f.e. deleting no >longer used files BUT keeping the non-CVS stuff (such as .htacces >files). Is there a CVS command to clean up this export directory (that >is, remove all exported stuff from a directory without affecting other >non-CVS stuff? I don't know of any. >3) Does anybody have experience with the combination of CVS and >databases? We would like to be able not only to retrieve older >versions of the software but also older versions of the database >structure. Any comments would be appreciated! We're working with storing the SQL files in CVS. Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 3 questions...
[EMAIL PROTECTED] wrote: > 1) If you check in sources with wrong permissions (for example you > forgot to set x-permissions) you have to manually chmod the file under > /var/cvs. But because the file is owned by the last changer, you > cannot do this from the webtool. Are there any other ways (through CVS > commands) to change permissions of existing CVS resources. Don't knw what webtool you're using, but any developer with write access to the file should be able to change the perms. > 2) We export CVS sources to a directory for internal testing and other > non-CVS content might be added in this stage. At some time we want to > export the newest release to the test environment, f.e. deleting no > longer used files BUT keeping the non-CVS stuff (such as .htacces > files). Is there a CVS command to clean up this export directory (that > is, remove all exported stuff from a directory without affecting other > non-CVS stuff? Nope. You should be able to script something using co/update instead of export and accessing the admin files (preferrably through cvs status or the like), though. > 3) Does anybody have experience with the combination of CVS and > databases? We would like to be able not only to retrieve older > versions of the software but also older versions of the database > structure. Any comments would be appreciated! If you can export the database structure in a text format, it's easy. All the databases I've played with would export their structure & even permissions as a series of SQL drop/create commands. Just check those files in. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Rick: How long was it we had, honey? Elsa: I didn't count the days. Rick: Well I did, every one of them. Mostly I remember the last one. The wow finish. The guy standing on the station platform in the rain with a comical look on his face because his insides had been kicked out. - Humphrey Bogart & Ingrid Bergman, _Casablanca_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
MT response and update -p command
Hello. I'm developing (together with Robert Greig and Thomas Singer) a cvs client library in Java for use with Netbeans - see http://javacvs.netbeans.org and SmartCvs http://www.smartcvs.com Lately we encontered something I personally consider a bug of cvs or at least confusing. Currently our library doesn't support the MT response. We support M, E which should be enough.. So we don't send the MT in valid-responses request. It actually works fine all the time, except one case. when doing update -p or checkout -p If the file doesn't end with a new-line, then the final line of the source is discarded. While debugging this behaviour and by comparing our client-server communication and the cvs.exe one, I realized the the final line is sent (as opposed to the rest of the file) with the MT response. And because we don't support it, the server decided to send nothing to us. I'm aware of the fact that it "hack" is used to set the right new-lining to the file being sent however IMHO it should at least send the wrong M response. Is this really a bug or do we have to support the MT response? Where to fill this bug? Is there any list of required responses and requests? I couldn't find anything like that in the Cvs client/server document.. Is there a more in-depth description of the MT response somewhere? Thanks a lot for your replies and advice. Milos Kleint [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
3 questions...
Hi, We are trying to develop a in-house CVS webtool for all our developers and content people (we're in web development). The following problems have arisen: 1) If you check in sources with wrong permissions (for example you forgot to set x-permissions) you have to manually chmod the file under /var/cvs. But because the file is owned by the last changer, you cannot do this from the webtool. Are there any other ways (through CVS commands) to change permissions of existing CVS resources. 2) We export CVS sources to a directory for internal testing and other non-CVS content might be added in this stage. At some time we want to export the newest release to the test environment, f.e. deleting no longer used files BUT keeping the non-CVS stuff (such as .htacces files). Is there a CVS command to clean up this export directory (that is, remove all exported stuff from a directory without affecting other non-CVS stuff? 3) Does anybody have experience with the combination of CVS and databases? We would like to be able not only to retrieve older versions of the software but also older versions of the database structure. Any comments would be appreciated! thanks, Robert ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Tags in keyword substituions ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sthere a way to put the newest Tag of each file into the files by using keyword substitutions ?? Thanks ! Peter Biechele - -- # Dr. Peter Biechele, E-Mail: [EMAIL PROTECTED] beXtec GmbH, Kaiserstuhlstr. 3, 79312 Emmendingen Tel.: +49 7641 920869 41, Fax: +49 7641 920869 49 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bWjYkveh9aGZ5GcRAkX1AJ9cyf3Q01CXGROQTNnwVx6An07snwCfZlwp jafZ5iMCbcfo3fRWF52fbs4= =WcW/ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS/Entries.Log
Hi! First of all, thanks for your earlier cooperations. We are operating from two different locations. The source code sent to us by our parent company is imported into CVS (I am following the procedure as written in the manual - "Tracking Third Party Sources"). For the first four times, I ran the import command by simply changing the Release Tag. No changes were made from our side. We then checked out the latest revision and made few changes. I want to have a list of files that we have changed. I suppose for this, I will have to first commit the changes, tag the new revision and then run diff command. When I ran a cvs commit, it told me that the update check failed (for the very first file it examined). I then ran a cvs update with -j option. It then reported a conflict. I resolved the conflict and again tried to commit. Again the update check failed (this time for the next file changed). Will I have to repeat this procedure for all the files changed? When I tried cvs update before committing, It tells me: cvs [update aborted]: cannot open CVS/Entries.Log: Permission denied The problem is that I could not see any Entries.Log file anywhere. Now even when I run cvs status, there is same error message. Please help me in getting out of this situation as soon as possible. Thanks in advance. Regards, Manish _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Converting binary files to text
I did no follow the thread from the beginning, so may be, it has been already said. It is also possible to change the file without direct operations in the repo: cat /dev/null > filename.ext cvs ci -m 'kb -> kv' filename.ext cvs admin -kkv filename.ext copy file from good location cvs ci -m 'text version of the file' filename.ext By doing this you can fix repos, which are not directly accessible and keep the history of the change. Eugene. : -Original Message- : From: Dennis Jones [mailto:[EMAIL PROTECTED]] : Sent: Monday, January 22, 2001 11:12 PM : To: Larry Jones : Cc: CVS Mailing List : Subject: Re: Converting binary files to text : : : Right Larry, the order would have to be: : : rm filename.ext # remove the binary file : cvs rm filename.ext # remove the file from the repository : cvs ci filename.ext # commit the remove : : remove the original file from the Attic : : cvs ad filename.ext # add the new text file : cvs ci filename.ext # commit the add : : At this point, the repository is correct, and a 'cvs up -A' : by the user gets : him the correct file in his local trees. It's a little : convoluted, but it : seems to work. : : - Dennis : : : : - Original Message - : From: "Larry Jones" <[EMAIL PROTECTED]> : To: "Dennis Jones" <[EMAIL PROTECTED]> : Cc: <[EMAIL PROTECTED]> : Sent: Monday, January 22, 2001 9:07 PM : Subject: Re: Converting binary files to text : : : > Dennis Jones writes: : > > : > > Let me add some more information. Here is what I am : thinking MIGHT = : > > work: : > > : > > 1) Do a "cvs remove" on the original (binary, '-kb') file : > > 2) Do a "cvs add" and "cvs commit" using the text version : of the file : > : > Note that you have to commit the remove before you can : re-add the file. : > : > > Then when a developer does a "cvs update", his binary : version of a file : > > should get replaced with the text one. Sound like it will work? : > : > Nope. When you re-add the file, CVS will resurrect the : repository file, : > including the -kb flag. : > : > -Larry Jones : > : > ___ : > 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
