Empty val-tags file
Hi I've used now cvs for quite a while and never thought I'd run into such a problem. But anyway here it is. We tag our sources from time to time as it should be. But for some reason not all tags go into the val-tags file. In some repositories it's even empty. According to docu this shouldn't matter as cvs will refill it next time a tag is used. Problem is now that I get a no such tag error on some operations if it is not in the val-tags file. And I don't know what to do to get it in. Some operations work (log file, checkout module), some do not (diff, checkout file). But those that work don't update the val-tags file. If I manually add the tag in the val-tags file in the repo then also the other commands work (with exactly the same settings as before). But a different user had the same problems and adding the tag didn't help in his case (assuming he did it right). cvs log file: symbolic names: Version16: 1.10 VERSION15a: 1.9 VERSION15: 1.7 VERSION14: 1.7 VERSION13: 1.5 VERSION12: 1.4 cvs update -rVERSION15 file cvs.exe [update aborted]: no such tag VERSION15 A cvs init didn't help either. Apart from this problem everything else works (with the newest revision). I use cvs 1.11.1p1 on Windows, repo is local or network, no difference. I can't use 1.11.2 because of its problems on Windows and I haven't tried a cvs version. There are no problems with access rights. I'm sorry if this is a simple FAQ or newbie question or if it has been solved in the cvs version, but I couldn't find more info. Thanks Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using CVS to maintain XML
Wayne Johnson wrote: ... Anyone know a good way to manage XML in CVS? Is there a program that will sort an XML file? To make sure that similar tags always appear in the same order? Am I just dreaming? ... You could use a stylesheet, i.e. XSL (http://www.w3.org/Style/XSL/), and sort your tags with xsl:sort. There are a lot of XSL processors, e.g. sablotron (http://www.gingerall.com/). Stephan ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
Been watching this thread for a while... Here is my question: Are chrooted environments truly more secure than accessing pserver over an ssh tunnel? Yes, I know you can do both. There was some talk of local user accounts in a chrooted environment are more secure than connecting to pserver for instance. Personally I tend to believe that giving people any sort of local access (even in a chrooted environment for the user for instance) is more of a security risk than allowing pserver access over ssl/ssh, with the limited number of users having the key needed to connect (i.e. Auto-key negotiation disabled and so on). This limits the exposure of pserver to people already having the public key of the server (and their public key registered there). The way I have it set up here is that pserver and the cvsroots run as user cvs, which is an account w/o a shell, but a home directory (the cvsroots). Other users do not have any privileges in the cvs directories. Since the network is trusted, encryption over the network is not necessary here, but it would be possible to set up. The passwd and readers files, while living in the $CVSROOT/CVSROOT directory are not part of the repository (i.e. No ,v files) and so cannot be modified by any users. Advantages: - separate user management per cvsroot via the cvs passwd and readers files (i.e. Local account != cvs access) - optional connectivity with ssh (and potentially limiting access not only by user, but also by valid keys) - users on the local machine do not have read or write access to the repository (except when connecting via pserver too, of course, but the point is that they cannot go in and muck around with the actual files in the repository) Disadvantages: - if someone did a buffer overflow attack and could get a shell, they would have access to the cvsroots (but a chroot environment does not prevent that, it just limits access to other binaries and directories) - obviously, the ssh tunnel is potentially vulnerable to overflow attack - attackers could get the keys needed to attack pserver directly by cracking the accounts of the remote users - changing the user's password requires admin intervention (a huge pain for bigger sites i suppose) Cheers, Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 5:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Security, audits and pserver --- Forwarded mail from [EMAIL PROTECTED] --- Paul Sander [EMAIL PROTECTED] wrote: A chroot environment is only good at containing what's inside it. It does not prevent access to the chroot environment from outside. I see. I guess it's obvious that the repository would have to be within the chroot'ed environment meaning that such an environment wouldn't help in preventing users from directly accessing the archive files. Is this right? This is correct, provided the users (or other services) aren't confined to their own (non-overlapping) chroot environments. --- End of forwarded message from [EMAIL PROTECTED] ___ 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
cvslocks dir in $CVSROOT
Hi, I've created a CVS repository. I would like to know if it is really necessary to mkdir cvslocks dir for every repository that I create. Also,What would happen if I don't specify LockDir in $CVSROOT/config file? But I have cvs logins specified in $CVSROOT/readers and $CVSROOT/writers file. Is that not enough to handle read/write permissions for cvs logins. Can somebody explain me about this? Thanx! Jayashree *** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs [server aborted]:
Hi (BAm getting the following error. (BDoes anyone know, what could be the problem. (B--- (BDoes anyone know how to solve this error : (B (Bcvs [server aborted]: User 'user' cannot change c://cvsrepo/test/TeamTest (B (Bwhere c://cvsrepo/test/TeamTestsis my repository location (B--- (BThanks in advance (BSatish. (B (B (B___ (BInfo-cvs mailing list ([EMAIL PROTECTED] (Bhttp://mail.gnu.org/mailman/listinfo/info-cvs
RE: security question
Password-protected keys help protect them against theft. I would encourage everyone to use such keys. Or did I misunderstand your post? Are you talking about ssh-agent, or passphrase-based ssh keys, or an external layer of encryption on the keyfiles, or what? Please be specific. ssh-agent, for instance, would be a bit more secure, as long as you're sitting down at the console of one SSH-equipped workstation, and don't mind taking a minute to systematically startup ssh-agent connections to each host with which you plan to communicate during that session. My biggest problem with any of these approaches, besides the inconvenience, is they eliminate the opportunity for secure, automated batch processes. I have various cron jobs that fire off automatically, connect to different servers, do reports/extracts/whatever, and so on. For that, AFAIK, you need to store your keys in the filesystem. Correct me if I'm wrong, but as long as your private key is chmod 600, the only way it will be compromised is if your local workstation gets rooted. If that happens, ssh-agent itself can be quickly trojaned with a compromised copy that collects passwords. Likewise, if you're just using passphrase-encrypted keys, ssh and cvs themselves are both compromised on a rooted box...so what's the difference? Or am I missing something? Thanks...this is more interesting than listening in on pserver discussions :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Vendor branches, imports and checkouts
I've just been surprised by cvs import, and I'm having a hard time deciding who's wrong and how to best approach the problem. What's a poor geek to do? We've got a CVS repository here that contains a modified version of the NetBSD kernel. We built it by importing the source as a vendor branch (lots of untarring, then cvs import $REPONAME NETBSD NETBSD_1_5 usr/src/). Over time, we've modified a number of files, checking them out and back in appropriately. Now we've begun to update to the next kernel release (another round of untarring, then cvs import $REPONAME NETBSD NETBSD_1_6 usr/src/), and my colleagues are receiving the changes (via cvs update) even though they haven't been merged into the main trunk yet. I've advised them to checkout the head revision (cvs checkout -r HEAD ...) and work on that while I try to figure things out - I think that's the right plan. All our changes have been checked in to the main trunk, with branches off the trunk whenever we freeze a release, and release-specific bugfixes checked in to the correct branches. So we have a main trunk of active development (1.1, 1.2, ...) with some branches off it (1.2.2, 1.5.2, etc) for fixes (1.2.2.1, 1.2.2.2, ...; 1.5.2.1, 1.5.2.2, ..., etc.) and a vendor branch (1.1.1) containing the imported releases (1.1.1.1, 1.1.1.2, ...). I'm very surprised that cvs update from within a checked-out working directory picked up the newly imported NetBSD 1.6 revisions (1.1.1.2) for the files we haven't modified. The head revision is still on the 1.1 revision (verified from the RCS files and via cvsgraph), and based on reading the Cederqvist and other sources (but not the CVS source - yet), I'd expect the vendor branch to be a stub off the main trunk and for it to have no impact on an unqualified cvs checkout. Have I misunderstood the interactions between import, checkout and update? Should I have told my colleagues all along to cvs checkout -r HEAD so they stay on the main trunk? Thanks, Ross -- Ross A. Patterson CatchFIRE Systems, Inc. 5885 Trinity Parkway, Suite 220 Centreville, VA 20120 (703) 563-4164 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT must be an absolute pathname problem
Mike Ayers writes: I do not think it is possible to use WinCVS and Cygwin compiled CVS on the same sandbox. Cygwin CVS expects ALL files to be in Unix mode. While WinCVS can check out sandbox files with Unix line endings, it should still expect the CVS/* files to use Windows line endings. You must choose one tool or the other. I believe it is possible, provided you configure Cygwin to use DOS line endings when you install CVS. (There may be a way to specify DOS line endings at run-time, too; I don't know a whole lot about Cygwin). Conversely, WinCVS comes with a command-line CVS; you can just use it directly (by adding the WinCVS directory to your PATH) rather than using the Cygwin version. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Security, audits and pserver
Walter, Jan writes: Personally I tend to believe that giving people any sort of local access (even in a chrooted environment for the user for instance) is more of a security risk than allowing pserver access over ssl/ssh, with the limited number of users having the key needed to connect (i.e. Auto-key negotiation disabled and so on). This limits the exposure of pserver to people already having the public key of the server (and their public key registered there). Note that giving anyone pserver access to a machine is equivalent to giving them local shell access -- there are fairly simple tricks that can be used to execute arbitrary code on the server. CVS was not designed as a security application, it was designed as a collaboration application for cooperative users. -Larry Jones Let's just sit here a moment... and savor the impending terror. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvslocks dir in $CVSROOT
Jayashree writes: I've created a CVS repository. I would like to know if it is really necessary to mkdir cvslocks dir for every repository that I create. Also,What would happen if I don't specify LockDir in $CVSROOT/config file? If you don't specify LockDir= in the config file, locks for a repository directory go into the repository directory itself. If all the users who are allowed to read or write a directory have write permission on that directory, then that works just fine. If not, you have to set LockDir. Note that you only have to set LockDir for each *repository*, not each top-level directory; most people just have one repository. -Larry Jones It's no fun to play games with a poor sport. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: security question
Zieg, Mark wrote: My biggest problem with any of these approaches, besides the inconvenience, is they eliminate the opportunity for secure, automated batch processes. I have various cron jobs that fire off automatically, connect to different servers, do reports/extracts/whatever, and so on. For that, AFAIK, you need to store your keys in the filesystem. Correct me if I'm wrong, but as long as your private key is chmod 600, the only way it will be compromised is if your local workstation gets rooted. If that happens, ssh-agent itself can be quickly trojaned with a compromised copy that collects passwords. Likewise, if you're just using passphrase-encrypted keys, ssh and cvs themselves are both compromised on a rooted box...so what's the difference? Or am I missing something? There's a tool called keychain [1] that acts as a frontend to ssh-add and ssh-agent. It will allow one to use password encrypted keys in crons as you suggest, and eliminates the hassle of adding your keys to your agent every session. YMMV. [1]: http://www.gentoo.org/proj/en/keychain.xml that -- Scott Moynes Canadian Bank Note Co. Ltd. [EMAIL PROTECTED] (613) 225-3018 x2272 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor branches, imports and checkouts
Ross Patterson writes: Have I misunderstood the interactions between import, checkout and update? Yes. Please re-read the section of the manual on tracking third-party sources: http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 Pay particular attention to the details about the 'head' revision. -Larry Jones I kind of resent the manufacturer's implicit assumption that this would amuse me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
That's why you would tunnel it over ssh or something like that, with limited key access. People you trust get the key, and their key gets kept on the server. Definitely, a wide-open pserver connection is just an invitation to get cracked. Jan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 5:13 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Security, audits and pserver Walter, Jan writes: Personally I tend to believe that giving people any sort of local access (even in a chrooted environment for the user for instance) is more of a security risk than allowing pserver access over ssl/ssh, with the limited number of users having the key needed to connect (i.e. Auto-key negotiation disabled and so on). This limits the exposure of pserver to people already having the public key of the server (and their public key registered there). Note that giving anyone pserver access to a machine is equivalent to giving them local shell access -- there are fairly simple tricks that can be used to execute arbitrary code on the server. CVS was not designed as a security application, it was designed as a collaboration application for cooperative users. -Larry Jones Let's just sit here a moment... and savor the impending terror. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [server aborted]:
HALESHAPPA SATHEESHA writes: cvs [server aborted]: User 'user' cannot change c://cvsrepo/test/TeamTest That message doesn't seem to appear anywhere in the source code -- what versions (client and server) of CVS are you running, what platforms are you running on, and what is the exact command that results in the error? -Larry Jones Everybody's a slave to routine. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Empty val-tags file
Problem is now that I get a no such tag error on some operations if it is not in the val-tags file. And I don't know what to do to get it in. Some operations work (log file, checkout module), some do not (diff, checkout file). But those that work don't update the val-tags file. If I manually add the tag in the val-tags file in the repo then also the other commands work (with exactly the same settings as before). But a different user had the same problems and adding the tag didn't help in his case (assuming he did it right). He didn't. To determine if a tag is valid, CVS first checks the val-tags file. If the tag does not appear there, the specified files (NOT the entire repository) are scanned for the tag. If it appears in any of them, it is valid and is added to the val-tags file (unless you've specified the global -n flag). If you're getting no such tag, then the tag really doesn't exist in any of the file you specified for the command (although it may exists in other files that you haven't specified). Commands like log don't require a valid tag -- you get generic log information in any case -- but you *do* get a warning that you perhaps overlooked. I think I did it right and there was *no* warning. But maybe you can help me with this output. Sorry, I'm clueless. cvs.exe log VarioSam\Applicat\Src/Iologger.cpp RCS file: n:\temp\variosam/VarioSam/Applicat/Src/Iologger.cpp,v Working file: VarioSam\Applicat\Src/Iologger.cpp head: 1.10 branch: locks: strict access list: symbolic names: Version16: 1.10 VERSION15a: 1.9 VERSION15: 1.7 VERSION14: 1.7 VERSION13: 1.5 VERSION12: 1.4 ROOT_Version: 1.4 Ver1_1_VM: 1.2 Ver1_1: 1.2 V_1_00: 1.1.1.1 ZuK: 1.1.1 keyword substitution: kv total revisions: 11;selected revisions: 11 description: revision 1.10 date: 2002/12/13 14:01:48; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.9 date: 2002/12/13 13:57:39; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.8 date: 2002/12/11 14:43:27; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.7 date: 2002/12/11 14:20:55; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.6 date: 2002/12/11 14:09:22; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.5 date: 2002/12/11 13:18:34; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.4 date: 2002/12/11 13:17:04; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.3 date: 2002/12/11 13:09:11; author: VMarquardt; state: Exp; lines: +1 -1 I should enter a message here revision 1.2 date: 2002/12/11 12:57:06; author: VMarquardt; state: Exp; lines: +1 -310 I should enter a message here revision 1.1 date: 2002/09/19 13:43:18; author: FABI; state: Exp; branches: 1.1.1; Initial revision revision 1.1.1.1 date: 2002/09/19 13:43:18; author: FABI; state: Exp; lines: +0 -0 Initial import = cvs.exe update -rVERSION15 VarioSam\Applicat\Src\Iologger.cpp cvs.exe [update aborted]: no such tag VERSION15 Thanks bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Empty val-tags file
Fabian Cenedese writes: cvs.exe update -rVERSION15 VarioSam\Applicat\Src\Iologger.cpp cvs.exe [update aborted]: no such tag VERSION15 Hmmm. Perhaps the backslashes are confusing CVS (you should always use forward slashes with CVS); try using forward slashes and see if that solves the problem. If not, please run the command with tracing enabled (the global -t option) and post the trace. -Larry Jones Things are never quite as scary when you've got a best friend. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Empty val-tags file
Fabian Cenedese writes: We tag our sources from time to time as it should be. But for some reason not all tags go into the val-tags file. In some repositories it's even empty. According to docu this shouldn't matter as cvs will refill it next time a tag is used. CVS doesn't add tags to the val-tags file when they're created, only when they're referenced. Many times tags are applied just in case and never actually get used -- not recording them until they're used keeps the val-tags file lean and mean. Problem is now that I get a no such tag error on some operations if it is not in the val-tags file. And I don't know what to do to get it in. Some operations work (log file, checkout module), some do not (diff, checkout file). But those that work don't update the val-tags file. If I manually add the tag in the val-tags file in the repo then also the other commands work (with exactly the same settings as before). But a different user had the same problems and adding the tag didn't help in his case (assuming he did it right). He didn't. To determine if a tag is valid, CVS first checks the val-tags file. If the tag does not appear there, the specified files (NOT the entire repository) are scanned for the tag. If it appears in any of them, it is valid and is added to the val-tags file (unless you've specified the global -n flag). If you're getting no such tag, then the tag really doesn't exist in any of the file you specified for the command (although it may exists in other files that you haven't specified). Commands like log don't require a valid tag -- you get generic log information in any case -- but you *do* get a warning that you perhaps overlooked. -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor branches, imports and checkouts
On Monday 16 December 2002 11:29 am, Larry Jones wrote: Ross Patterson writes: Have I misunderstood the interactions between import, checkout and update? Yes. Please re-read the section of the manual on tracking third-party sources: So I guess I should have read: When you import a new file, the vendor branch is made the `head' revision, so anyone that checks out a copy of the file gets that revision. When a local modification is committed it is placed on the main trunk, and made the `head' revision. as saying that any further changes to the vendor branch would impact the head revision until and unless there was a local change committed to the main trunk. I guess that makes sense and is clear in hindsight, but as many times as I've read that text I never noticed that it said ... vendor branch ..., and always thought what it meant was the newly-created revision became the head, not the branch itself. On a related topic, I've recently read in the list archives about the implications of cvs import and newly-deleted files and that the proper next step after cvs import is cvs update -j prev_level -j new_level to make them actually happen (although neither the CVS manual nor Karl Fogel's book seem to touch on this). That's part of what lead me to expect that importing an updated vendor source tree wouldn't impact main-trunk users. But I now understand that If that's the behavior I want, I need to do something else. Like explictly making the main trunk the current branch via cvs admin -b some level I need to figure out, or perhaps forcing a gratuitous change that pulls all the code down to the main trunk. Thanks for the help, Ross -- Ross A. Patterson CatchFIRE Systems, Inc. 5885 Trinity Parkway, Suite 220 Centreville, VA 20120 (703) 563-4164 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
The advantage to chroot environments is that they can limit exposure to things like rogue *info scripts that might reach beyond the CVS repository. This is handy in the event that you store sensitive data on the machine in addition to the repository. The biggest argument in favor of user accounts is that the operating system is much better at authenticating users, logging their activities, and enforcing access controls than the CVS application is. And if a user manages to break out of the application somehow, he's not anonymous and you know where to turn when things go bad. So the answer to your question is yes, and no. --- Forwarded mail from [EMAIL PROTECTED] Are chrooted environments truly more secure than accessing pserver over an ssh tunnel? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Security, audits and pserver
[ On Monday, December 16, 2002 at 17:16:41 (+0100), Walter, Jan wrote: ] Subject: RE: Security, audits and pserver That's why you would tunnel it over ssh or something like that, with limited key access. People you trust get the key, and their key gets kept on the server. Definitely, a wide-open pserver connection is just an invitation to get cracked. No, that's why you'd use SSH plain and simple with real, proper, unique system accounts for every real person, and never use CVSpserver, not even tunneled, because even with the tunnel you end up having no possibility of achieving even minimal accountability -- any CVSpserver user can trivially spoof any other at several levels. CVS is _NOT_ a security application, nor is it a multi-user operating system kernel. -- 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
Ignore no revision warning in cvs log
Is there a way to ignore the no revision warning message when using the cvs log command? I am using a CVS build that I checked out from around 11/11/02 timeframe to use the new cvs log -r tag1::tag2 syntax. But if tag1 does not exist in the file (e.g., a new file that was added), CVS currently gives a warning but doesn't print any log information. I would think you still want to see the log for tag2. Otherwise there is no way to know a file was added. Thanks, -- Patrick Lee [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: local tagging
Hi folks-
Last week I inquired about how to do the equivalent of a tag without writing to the
repository. I
wrote a couple of TCL scripts which I believe do what I want, and I'd like to offer
them to the cvs
community for your use and solicit feedback from anyone who might be interested in
them. I'd like to
know if there are any special cases that I've neglected to handle, and any other
opportunities for
improvement. They are attached below.
thanks,
Chris
-Original Message-
From: Volpe, Christopher R (Research)
Sent: Tuesday, December 10, 2002 11:12 AM
To: '[EMAIL PROTECTED]'
Subject: local tagging
Hi folks-
I'm new to the list, so I apologize if this has been asked.
I perused the last few months of
archived messages, but couldn't find the FAQ referred to on
http://mail.gnu.org/mailman/listinfo/info-cvs.
Anyway, here's what I'd like to be able to do. I want to
have the equivalent functionality of a
tag, but without actually writing to the repository. That is,
I want to record the state of the
revisions of all the files in my working directory so that I
can revert to that state at a later
time. But I don't want to modify the repository itself, for a
couple of reasons:
1) The repository is shared by a large community, and the
owners don't like the prospect of having a
user (much less *many* users) creating more than one or two
tags a year.
2) The functionality needs to be available from a shared
testing account that has read-only anonymous
access to the repository.
Now, the straightforward solution would be to write a script,
or a pair of scripts, that does a cvs
status, and parses the output and writes it out in a
condensed form, and another that reads this
condensed form and pulls out all the specified file
revisions. However, before I go reinventing the
wheel, I'd like to know if there exists such a tool already,
possibly with more bells and whistles
than I was planning to implement. Thanks in advance for any
information you can provide.
Chris
GE Global Research Center
__
_
___
Dr. Christopher R. Volpe, Ph.D.
Computer Scientist
Visualization and Computer Vision Lab
Imaging Technologies
Bldg KW, Room C215
P.O. Box 8, Schenectady, NY 12301
(518) 387-7766, Dial Comm: 8*833-7766, Fax: (518) 387-6981
e-mail: [EMAIL PROTECTED]web: http://www.crd.ge.com/~volpecr
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
begin 600 restorestate.tcl
M(R%T8VQS:#@S+F5X90T*(R!:6QE.B!R97-T;W)EW1A=4N=-L#0HC($%U
M=AOCH@0VAR:7-T;W!H97(@5F]L4-B,@15S8W)I'1I;VXZ(%)E=')I
M979E('1H92!S5C:69I960@F5V:7-I;VYS(]F(%L;!W;W)K:6YG#0HC
M(`@9FEL97,@8V]RF5S]N9EN9R!T;R!A(MN;W=N+6=O;V0@V%V960@
MW1A=4N($EF('1H97)E(`T*(R`@(%R92!L;V-A;!M;V1S(EN('1H92!C
M=7)R96YT('=OFMI;F@=F5RVEO;BP@;6%K92!A()A8VMU!O9B`-B,@
M(!T:4@9FEL92!A;F0@'5L;!O=70@82!FF5S:!C;W!Y('=I=AO=70@
M=AE(QO8V%L(UO9',-B,-FEF('LD87)G8R`A/2`Q('T@PT*(!EG)O
MB`B57-A9V4Z(')EW1OF5S=%T92`\W1A=5F:6QE/B(-GT-@T*(R!'
MF%B('1H92!R97!OVET;W)Y)W,@8F%S92!P871H('-O('1H870@=V4@8V%N
M('-U8G1R86-T(ET#0HC(9R;VT@=AE('!A=@@;V8@96%C:!F:6QE(EN
M(]R95R('1O(]B=%I;B!A(9I;4-B,@%T:!W92!C86X@=7-E(EN
M($@8W9S(-O;6UA;F0-G-E=!R97!F:6QE(%MO5N((N+T-64R]297!O
MVET;W)Y(B!R70T*V5T(')E%]S=')?;5N(%MG971S(1R97!F:6QE(')E
M%T-G-E=!F:7)S=!;97APB`DF5P7W-TE]L96X@*R`Q70T*8VQOV4@
M)')E9I;4-@T*(R!=6EL9!A;B!I;G1EFYA;!S=%T=7,M9%T86)A
MV4-B,@4W1AG0@F5A9EN9R!T:4@W1A='5S(]F(5A8V@@9FEL92P@
M;VYE(%T($@=EM90T*V5T('-T871UV]U=!;;W!E;B`B?-VR!S=%T
M=7,B(')=#0H-B,@26YD:6-A=5S('=H971H97(@;W(@;F]T('1O(9OF-E
M($@F4M;]A9P@979E;B!I9B!T:4@#0HC('=OFMI;F@F5V:7-I;VX@
M:7,@=AE('-A;64@87,@=AE(YE961E9!R979IVEO;@T*V5T(9OF-E
M7W)E;]A9`P#0H-B,@:6YD:6-A=5S('=H971H97(@;W(@;F]T('=E(YE
M960@=\@='5C:R!A=V%Y('1H92!EES=EN9R!F:6QE#0HC('-O('1H870@
M=V4@8V%N(]B=%I;B!A(-L96%N(-O'D@;V8@=AE(9I;4-G-E=!T
M=6-K7V%W87D@,`T*#0IW:EL92![6V5O9B`DW1A='5S;W5T72`A/2`Q?2![
M#0H@(=E=',@)'-T871UV]U=!L:6YE#0H@(`T*(`C($%R92!W92!L;V]K
M:6YG(%T($@;EN92!O9B!T:4@9F]R;2`B1FEL93H@/9I;4^(%-T871U
MSH@/'-T871USXB/PT*(!I9B![6VQI;F1E`D;EN92`P72`]/2`B1FEL
M93HB(8F(%ML:6YD97@@)QI;F4@,ET@/3T@(E-T871USHB?2![#0H@(`@
MV5T('=OFMI;F=?9FEL92!;;EN95X(1L:6YE(#%=#0H@(`@V5T('-T
M870Q(%ML:6YD97@@)QI;F4@,UT-B`@(!S970@W1A=#(@6VQI;F1E`D
M;EN92`T70T*(`@(EF('LH)'-T870Q(#T](),;V-A;QY(B`F)B`DW1A
M=#(@/3T@(DUO9EF:65D(BD@?'P-B`@(`@(`@*1S=%T,2`]/2`B1FEL
M92(@)B8@)'-T870R(#T]()H860B*2!\?`T*(`@(`@(`H)'-T870Q(#T]
M().965DR(@)B8@)'-T870R(#T]()-97)G92(I?2![#0H@(`@(!S970@
M9F]R8V5?F5L;V%D(#$-B`@(`@('-E=!T=6-K7V%W87D@,0T*(`@('T-
MB`@?0T*(`@(`T*(`C($ES('1H92!F:6QE(UIW-I;F_#0H@('-E=!S
M=%T,2!;;EN95X(1L:6YE(#%=#0H@('-E=!S=%T,B!;;EN95X(1L
M:6YE(#)=#0H@(EF('LH)'-T870Q(#T]()N;R(@)B8@)'-T870R(#T]()F
M:6QE(BE]('L-B`@(`C($AA;F1L92!C87-E('=H97)E('1H92!L;V-A;!F
RE: security question
--- Zieg, Mark [EMAIL PROTECTED] wrote: Password-protected keys help protect them against theft. I would encourage everyone to use such keys. Or did I misunderstand your post? Are you talking about ssh-agent, or passphrase-based ssh keys, or an external layer of encryption on the keyfiles, or what? Please be specific. I previously posted saying that SSH keys should be password-protected and that if they were, one can run ssh-agent so that one needn't type in the password each time, or type in the password for each use. ssh-agent, for instance, would be a bit more secure, as long as you're sitting down at the console of one SSH-equipped workstation, and don't mind taking a minute to systematically startup ssh-agent connections to each host with which you plan to communicate during that session. In the past, I had set up my system to start up ssh-agent upon first login. It wasn't such a big deal. My biggest problem with any of these approaches, besides the inconvenience, is they eliminate the opportunity for secure, automated batch processes. I don't see how. So long as there's an already-running ssh-agent, a batch process can use it. True, if the machine were rebooted, there'd be no automated way to recover, but hey, that's the price for more security. I have various cron jobs that fire off automatically, connect to different servers, do reports/extracts/whatever, and so on. For that, AFAIK, you need to store your keys in the filesystem. AFAIK, the keys need to be stored on the filesystem in any SSH setup. If you meant that the keys can't be password-protected, like I said, just have ssh-agent running in the background (then have your cron job 'ps' to get the ssh-agent PID). Correct me if I'm wrong, but as long as your private key is chmod 600, the only way it will be compromised is if your local workstation gets rooted. Maybe. One question I've had in the past is whether keys should be backed up or not. If they are, there's now at least one copy of them. I believe this increases the chances (even minutely) of them falling into the wrong hands. In the end, if you haven't done a complete security audit of the entire backup procedures, you can't trust them to be secure. If that happens, ssh-agent itself can be quickly trojaned with a compromised copy that collects passwords. This is one reason why I'd like trusted OS's (eg no one user, including root, is all-powerful) to take off faster but that's another topic. Likewise, if you're just using passphrase-encrypted keys, ssh and cvs themselves are both compromised on a rooted box...so what's the difference? Or am I missing something? If you're assuming that the only compromise possible for keys is a root compromise then you are correct. How sure are you that that's the only compromise? Thanks...this is more interesting than listening in on pserver discussions :-) I agree :-) Noel __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
single file
hi, is it possible cvs to control only one file? how to do that? thanks, ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: single file
Nugroho Nursuwito wrote: is it possible cvs to control only one file? how to do that? Have one repository, one module and only file. It is as simple as that.. Cheers. Mahantesh. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
i could not connect the cvs pserver from cvs client on win32
i have setup a cvs server,then i try connect the server from a win32 machine.but failed.the error message is [login aborted]:reading from server:connection reset by peer or [login aborted]:end of file from server,consult above message if any. i think my cvs pserver is mistake.how could i do? Thanks. _ Do You Yahoo!? ÄúÏëÏíÊÜ2£7ÕÛÐǼ¶¾Æµê¼Û¸ñÂ𣿠http://cn.travel.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Empty val-tags file
cvs.exe update -rVERSION15 VarioSam\Applicat\Src\Iologger.cpp cvs.exe [update aborted]: no such tag VERSION15 Hmmm. Perhaps the backslashes are confusing CVS (you should always use forward slashes with CVS); try using forward slashes and see if that solves the problem. If not, please run the command with tracing enabled (the global -t option) and post the trace. I know that cvs uses forward slashes but it wasn't a problem to use backward so I stuck with that. But it didn't change anything anyway. cvs.exe -t update -rVERSION15 VarioSam/Applicat/Src/Iologger.cpp - main loop with CVSROOT=:local:n:\temp\variosam cvs.exe [update aborted]: no such tag VERSION15 That was all. Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
