Help with moving repository
We are in the process of moving our cvs repository (pserver) for reasons of size and speed, and have so far asked our CVS users to ensure everything is checked in to the existing repository, remove the existing working copies then modify their CVSROOT or -d options and check out again from the address of the new repository (which is actually a mount point for the moment from the old one, until everyone sets up correctly, then it will be copied to its proper location at a convenient point). Some of our developers are complaining that this is going to take them too long (don't ask, I've already had the argument with them). Is there a utility available anywhere to perform global changes to the cvs metadata in a users working copy. For instance change the entry in cvs/root from :pserver:user@oldcvs:/cvs/cvsroot to :pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere has done this before. If such a thing were available, it may just save me a few headaches. Thanks Mark Cooper Any views or opinions presented in this Email message are solely those of the author and do not necessarily represent those of the Microlise Group unless otherwise specifically stated. Email communications are not necessarily secure and therefore the Microlise Group does not accept legal responsibility for the contents of this message. If you are not the intended recipient and have received this message in error, please notify Microlise immediately. Microlise Group Limited +44 (0)1773 537000 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: connection using pserver
Kenneth Porter wrote: --On Friday, January 17, 2003 4:46 PM -0500 Larry Jones [EMAIL PROTECTED] wrote: If you're at all concerned about security, you should not be using pserver, you should be using :ext: with SSH. We started down this path but couldn't get it working on Windows with cygwin ssh. (Server is a Red Hat box, though.) Is there a cookbook somewhere that explains how to make that scenario work? For other tunneling (eg. X) I've been using the latest PuTTY, which seems to work pretty well. Has anyone set up a Windows CVS client using PuTTY? Yes. The PuTTY documentation http://www.chiark.greenend.org.uk/~sgtatham/putty/docs.html includes everything you should need for the authentication and connection end of things. I'm using WinCVS 1.3.6.1 Beta 6 (Local Build 1). The 1.2x series didn't seem to play nice with the PuTTY suite, and more current versions may also have issues. The only trick I can think of is that my $CVSROOT uses a PuTTY session vs. the real server name. -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: connection using pserver
Kenneth Porter wrote: --On Friday, January 17, 2003 4:46 PM -0500 Larry Jones [EMAIL PROTECTED] wrote: We started down this path but couldn't get it working on Windows with cygwin ssh. (Server is a Red Hat box, though.) Is there a cookbook somewhere that explains how to make that scenario work? For other tunneling (eg. X) I've been using the latest PuTTY, which seems to work pretty well. Has anyone set up a Windows CVS client using PuTTY? First, remember that you're not really tunneling with CVS the same way you're tunneling with X. The PuTTY suite provides plink, which has no interface or terminal integration and integrates very nicely with CVS. It can use PuTTY sessions and shares the cache of host keys in the registry, uses pageant, etc. Most of our Windows users use TortoiseCVS (http://www.tortoisecvs.org/), which integrates a customized version of plink. HTH Geoff ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
args to fchmod() and chmod()
Greetings, all. I notice that cvs in several places executes fchmod() or chmod(), and that in some cases the new mode argument is the mode returned from an earlier call to stat(). This value typically includes the file type. On most platforms this causes no problem, but OS/400 complains that the value specified for the argument is not correct. Indeed, the documentation of chmod() at http://www.opengroup.org/onlinepubs/007908799/xsh/chmod.html lists the bits which it can change and specifies that errno=EINVAL is a possible result, so I think that OS/400 is arguably correct. Does anybody forsee possible bad results from masking the mode argument down to the valid bits? Would the official cvs be willing to accept a patch to this effect? If this is a good idea, perhaps some expert can answer a couple of questions: (*) Where should I define the valid bits? Would anybody volunteer to help me with the configuration tools? Would anybody be willing to take over that part of the work? (*) sys/stat.h on different platforms define different subsets of the bits named in the Posix specification. In light experimentation on the platforms I have readily available, I have not seen any unnamed bit affect the value of the mode returned from stat(). How can I best define the valid bits portably? Thank you, all, for your attention. Terry. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help with moving repository
On Mon, 20 Jan 2003, Mark Cooper wrote:
Is there a utility available anywhere to perform global changes to the cvs
metadata in a users working copy. For instance change the entry in cvs/root
from :pserver:user@oldcvs:/cvs/cvsroot to
:pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere
has done this before.
A simple combination of find and sh should do:
find . -type d -name CVS -exec sh -c 'echo :pserver:... {}/Root' \;
Here's yet another reason to use Meta-CVS: only one CVS directory
to fiddle with if you ever have to.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help with moving repository
We are in the process of moving our cvs repository (pserver) for reasons of size and speed, and have so far asked our CVS users to ensure everything is checked in to the existing repository, remove the existing working copies then modify their CVSROOT or -d options and check out again from the address of the new repository (which is actually a mount point for the moment from the old one, until everyone sets up correctly, then it will be copied to its proper location at a convenient point). Is the CVS Server on a Linux/UNIX system? What are the clients being used? Are the users working with Windows (WinCVS) Clients or using CVS on UN*X boxes? Some of our developers are complaining that this is going to take them too long (don't ask, I've already had the argument with them). OK, will not ask... ;-) Is there a utility available anywhere to perform global changes to the cvs metadata in a users working copy. For instance change the entry in cvs/root from :pserver:user@oldcvs:/cvs/cvsroot to :pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere has done this before. There is such a utility available for WinCVS clients, I do not know about UN*X clients, but should be easy to make using awk and grep. For the WinCVS utility visit Oliver Giesens page on: http://people.freenet.de/ogiesen/readme.htm Also, Oliver has given a full FAQ on CVS at: http://people.freenet.de/ogiesen/newfaq.htm If such a thing were available, it may just save me a few headaches. Thanks Mark Cooper Hope these site and macros help, you could run them on UN*X based systems, but I am not too sure. Gagneet I hear that if you play the Windows XP CD backwards, you get a satanic message - --That's nothing. If you play it forward, it installs Windows XP! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to list diffs/logs for all elements since a particular tag?
David M. Karr writes: Ok, well, I figured out how to get the diffs listing, using cvs rdiff -rTAGNAME moduleName. I'm still not sure how to get the commit comments listing, although that is less important now that I can get the diffs listing. cvs rlog -rTAGNAME:: moduleName -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 forgets directories
Carsten Friedrich writes: I have the following problem: I have a repository with some subdirectories. The subdirectories are not empty. When I do a cvs co for the project, all files and subdirectories and files get checked out correctly. If I do a cvs update however (even immediately after the checkout) cvs reports all directories as unknown (commandline, WinCVS, and PCL-CVS). What version(s) of CVS are you running? What platform(s)? Local repository, or client/server? Is the project you're checking out a module defined in the CVSROOT/modules file or an actual directory in the repository? Can you run the checkout with tracing enabled (the global -t option) and post the output? It would also be helpful to know the contents of the CVS/Entries file in the checked-out directory. -Larry Jones You know how Einstein got bad grades as a kid? Well MINE are even WORSE! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: args to fchmod() and chmod()
Terrence Enger writes: I notice that cvs in several places executes fchmod() or chmod(), and that in some cases the new mode argument is the mode returned from an earlier call to stat(). This value typically includes the file type. On most platforms this causes no problem, but OS/400 complains that the value specified for the argument is not correct. Indeed, the documentation of chmod() at http://www.opengroup.org/onlinepubs/007908799/xsh/chmod.html lists the bits which it can change and specifies that errno=EINVAL is a possible result, so I think that OS/400 is arguably correct. Are you certain that it's the file type bits that are causing the problem? If so, I'd say that OS/400 is definitely *incorrect*. The above-referenced specification says that chmod sets the SUID, SGID, sticky, and permission bits of the file to the corresponding bits in the argument. There is no requirement that non-corresponding bits of the argument be set to any particular values. Does anybody forsee possible bad results from masking the mode argument down to the valid bits? Would the official cvs be willing to accept a patch to this effect? I can't see that it hurts anything, other than some people's sensibilities. If this is a good idea, perhaps some expert can answer a couple of questions: (*) Where should I define the valid bits? Would anybody volunteer to help me with the configuration tools? Would anybody be willing to take over that part of the work? As per the above spec, the valid bits are precisely: (S_ISUID | S_ISGID | S_ISVTX | S_IRWXU | S_IRWXG | S_IRWXO) -Larry Jones Nobody knows how to pamper like a Mom. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help with moving repository
Laurence Jones wrote: Also, to prevent this problem from reoccurring in the future, you should set up a virtual host name for your CVS server (something like cvs) Yep, we've done that :) (We saw it coming). Anyway, I've written a couple of small .bat files which do the trick for WinDoze client users. All you have to do is set the CVSROOT environment variable to what it should be then run the first batch file (changecvs.bat), from the root of the drive or directory where you have CVS working copies. changecvs.bat: for /R %%f in (CVS\Root) do call changeroot.bat %%f changeroot.bat: if not exist %1 goto end copy %1 %1.old echo %CVSROOT% %1 :end I tested it on my working copies and it worked a treat. Thanks to those who responded. Mark Cooper [EMAIL PROTECTED] (Larry Jones)@thor.sdrc.com on 20/01/2003 15:56:54 Sent by:[EMAIL PROTECTED] To:[EMAIL PROTECTED] (Mark Cooper) cc:[EMAIL PROTECTED] Subject:Re: Help with moving repository Mark Cooper writes: Is there a utility available anywhere to perform global changes to the cvs metadata in a users working copy. For instance change the entry in cvs/root from :pserver:user@oldcvs:/cvs/cvsroot to :pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere has done this before. Such utilities have been posted to the list before -- I suggest searching the archives. Also, to prevent this problem from reoccurring in the future, you should set up a virtual host name for your CVS server (something like cvs) and make it an alias for the actual machine name. If you have to move the repository again in the future, all you have to do is change the definition of the alias to point to the new machine, the users don't have to do anything at all. -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: Help with moving repository
Mark Cooper writes: Is there a utility available anywhere to perform global changes to the cvs metadata in a users working copy. For instance change the entry in cvs/root from :pserver:user@oldcvs:/cvs/cvsroot to :pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere has done this before. Such utilities have been posted to the list before -- I suggest searching the archives. Also, to prevent this problem from reoccurring in the future, you should set up a virtual host name for your CVS server (something like cvs) and make it an alias for the actual machine name. If you have to move the repository again in the future, all you have to do is change the definition of the alias to point to the new machine, the users don't have to do anything at all. -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: CVSROOT write permission vulnerability
On Mon, Jan 20, 2003 at 10:53:38AM -0500, Larry Jones wrote: As CVSROOT requires write permission, it has 777 permission for all. Setting the sticky bit (chmod -t) on a directory prevents normal users from deleting or renaming files in that directory unless they own them. Doing that in the repo would break CVS completely, wouldn't it? For most users, a commit would fail at the point where it tried to delete the old ,v file and rename the temporary copy (indeed, the sticky bit would independently block both of those operations). So only the owner of a given ,v file, and the owner of its parent directory, would be able to commit new revisions. To the original poster: Larry's main point still holds. Use client/server, not NFS. That'll also help you with the permissions problem, if you do it right. Doing it right has been discussed here many times; for details, try searching the list archives. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Windows CVS 1.11.4
There's quite a flaw with this CVS. It seems to open ever file as text, and not binary, therefore converting all \n's to \r\n. Even those lines that have \r\n on them.. so files checked out have \r\r\n when they're all done. I use a variety of CVS clients, many are the Cygwin port, which will preserve the \r\n's in the file, and put them in the repository, these, when checked out with the pure windows client are quite mangled... and also, a commit will indicate that ALL the files have changed, when in fact none of them have... this I thought originally wasa date issue... but I think that's not the problem... but then I don't know specifically how CVS decides if a file has changed... But, ya know, unless otherwise specified with an O_BINARY flag, open() on windows opens files in text mode? Jim ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Accessing CVS repositories using a www proxy (dev-http patch)
Hi, I am trying to access a remote CVS repository using pserver.. but I need to go through a proxy. I have read this page http://www.cvshome.org/cyclic/cvs/dev-http.txt which seems relevant to my problem, but this mail has been written in 1999, and I suspect things have quite changed since in CVS. - is there a patch for accessing remote repositories with the newest / newer CVS sources ? - or this patch been integrated in CVS sources ? - or has somebody else found a better way to do this ? Regards, Axelle. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
filter mails sending
How do you filter the mails sending for a group of or a e-mail direction, considering the extension of the file commited (in this case in particular rtf) Thanks in advance Luis C. González Coordinador de Proyectos Desarrollo de Sistemas - Tecnología Provencred - Citigroup ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Help with moving repository
On Mon, Jan 20, 2003 at 10:21:48AM +, Mark Cooper wrote:
We are in the process of moving our cvs repository (pserver) for reasons of
size and speed, and have so far asked our CVS users to ensure everything is
checked in to the existing repository, remove the existing working copies
then modify their CVSROOT or -d options and check out again from the
address of the new repository (which is actually a mount point for the
moment from the old one, until everyone sets up correctly, then it will be
copied to its proper location at a convenient point).
Some of our developers are complaining that this is going to take them too
long (don't ask, I've already had the argument with them).
Is there a utility available anywhere to perform global changes to the cvs
metadata in a users working copy. For instance change the entry in cvs/root
from :pserver:user@oldcvs:/cvs/cvsroot to
:pserver:user@newcvs:/cvs/cvsroot. I can imagine that someone somewhere
has done this before.
If such a thing were available, it may just save me a few headaches.
If you are simply moving repository from one machine to another (and
keeping the same path), you could set up port redirection/forwarding on
the old machine, so all incoming connections on the old pserver box are
transparantly forwarded to the new pserver box. This can be achieved by
redir(1) [it's available on Linux]. Or if you use xinetd i *believe* it
can do port forwarding too (haven't tried, YMMV).
This should allow developers to use either CVSROOT and remove the need
for a sudden switch. The downside is that there bound to be somebody
who forgets to switch, which you will only discover once the port
forwarding is switched off.
On a related note: If you're moving the repository across machines, how
do you identify the machines? If you have control over your DNS set-up,
you may just want to use:
pserver.yourhost.yourdomain.tld
[substitute as appropriate]
and let pserver be a canonical name for the real box. In this way,
you can move the repository to your hearts content provided that you
update DNS accordingly (and keep the same path within the box).
Any views or opinions presented in this Email message are solely those of
the author and do not necessarily represent those of the Microlise Group
[snip]
whatever...
just my 2 ${MONETARY_UNIT}/100...
--
Karl E. Jørgensen
[EMAIL PROTECTED] http://karl.jorgensen.com JabberID: [EMAIL PROTECTED]
Today's fortune:
Running Windows on a Pentium is like having a brand new Porsche but only
be able to drive backwards with the handbrake on.
(Unknown source)
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
update -j updates more than requested
Greetings, I'm having the following problem with 'update -j'. Any help is appreciated. I have an (untagged) working copy that was originally checked out from the main trunk. More files have been checked into the main trunk since then, so there are files/changes on the trunk that are not in my working copy. My working copy also has uncommitted adds/changes. I now want to merge in the changes from another branch made off of HEAD into my working copy. The branch is further down the trunk than my working checkout, but not at the end of the trunk. I expected the following to work: cvs update -j BRANCHTAG working_dir However, this not only merges in the changes from the branch, but it's ALSO brings my working dir up to date with the LATEST (past my checkout AND the branch) versions checked in on the main trunk. I only want the changes from the BRANCH, without picking up any changes on the trunk. 'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the same result, which is really strange. Anyone know how I can get what I want? BTW, this is CVS version 1.10.7. TIA... AJ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update -j updates more than requested
On Mon, 20 Jan 2003, Alicia Jones wrote: I have an (untagged) working copy that was originally checked out from the main trunk. More files have been checked into the main trunk since then, so there are files/changes on the trunk that are not in my working copy. My working copy also has uncommitted adds/changes. I now want to merge in the changes from another branch made off of HEAD into my working copy. The branch is further down the trunk than my working checkout, but not at the end of the trunk. Ah, well, then relative to you, that branch consists of all the main trunk work up to that branching point, and then all the work on the branch. I expected the following to work: cvs update -j BRANCHTAG working_dir However, this not only merges in the changes from the branch, but it's ALSO brings my working dir up to date with the LATEST (past my checkout AND the branch) versions checked in on the main trunk. I only want the changes from the BRANCH, without picking up any changes on the trunk. In that case, there has to be a branchpoint tag which marks the point on the trunk where the branch was made. You merge using: update -j branch-start-point -j branch This will do the right thing. If, alas, no such tag was made, you might be able to approximate it if you can guess the date and time when the branch was sprouted. People should practice making branchpoints. Without them, it's hard to take a branch to be a changeset which can be grafted into distant places in the revision tree. 'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the same result, which is really strange. Anyone know how I can get what I want? BTW, this is CVS version 1.10.7. You should consider upgrading to 1.11, though not specifically for this problem. A lot of debugging has happened since 1.10.7. There was a branchpoint patch floating around to add special syntax for implicitly referring to the base revisions of a branch, thereby avoiding the need for a branchpoint tag. I'm not sure whether this has been rolled into the official CVS sources. -- Meta-CVS: directory structure versioning; versioned symbolic links; versioned execute permission; versioned property lists; easy branching and merging and third party code tracking; all implemented over the standard CVS command line client -- http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: filter mails sending
Hi Luis Gonzalez, How do you filter the mails sending for a group of or a e-mail direction, considering the extension of the file commited (in this case in particular rtf) have a look into procmail (http://www.procmail.org) or into maildrop. This is a typical act of MDAs. If you want to modify mails I suggest you take a helping-script written in perl or something else. Regards, Ruprecht -- Ruprecht Helms IT-Service und Softwareentwicklung Tel/Fax.: +49[0]7621 16 99 16 Homepage: http://www.rheyn.de email: [EMAIL PROTECTED] -- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update -j updates more than requested
Kaz Kylheku wrote: On Mon, 20 Jan 2003, Alicia Jones wrote: I have an (untagged) working copy that was originally checked out from the main trunk. More files have been checked into the main trunk since then, so there are files/changes on the trunk that are not in my working copy. My working copy also has uncommitted adds/changes. I now want to merge in the changes from another branch made off of HEAD into my working copy. The branch is further down the trunk than my working checkout, but not at the end of the trunk. Ah, well, then relative to you, that branch consists of all the main trunk work up to that branching point, and then all the work on the branch. Yes, but fortunately I was able to successfully bring my working dir up to date with the point where the branch forked off without problem (using a regular cvs update). So I really should take that out of the equation. Let's assume I was up-to-date at the time the branch was forked. I expected the following to work: cvs update -j BRANCHTAG working_dir However, this not only merges in the changes from the branch, but it's ALSO brings my working dir up to date with the LATEST (past my checkout AND the branch) versions checked in on the main trunk. I only want the changes from the BRANCH, without picking up any changes on the trunk. In that case, there has to be a branchpoint tag which marks the point on the trunk where the branch was made. You merge using: update -j branch-start-point -j branch I think that's what I'm doing... I have a cvs branch tag (BRANCHTAG) on the branch which of course points to the end of the branch I want. I also have a regular (i.e. non-branch) tag (BPOINTTAG) on the main trunk at the point where the branch I want forked off from the trunk. So it seems that either of: update -j BRANCHTAGOR update -j BPOINTTAG -j BRANCHTAG should have worked. However, both of these command get me both the changes on the branch AND the changes between the revisions currently in my working dir and the most recent checkins on HEAD. It's as if it doing both the 'cvs update -j 1 -j 2' AND a regular 'cvs update'. I didn't think that's what was supposed to happen. This will do the right thing. If, alas, no such tag was made, you might be able to approximate it if you can guess the date and time when the branch was sprouted. People should practice making branchpoints. Without them, it's hard to take a branch to be a changeset which can be grafted into distant places in the revision tree. 'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the same result, which is really strange. Anyone know how I can get what I want? BTW, this is CVS version 1.10.7. You should consider upgrading to 1.11, though not specifically for this problem. A lot of debugging has happened since 1.10.7. There was a branchpoint patch floating around to add special syntax for implicitly referring to the base revisions of a branch, thereby avoiding the need for a branchpoint tag. I'm not sure whether this has been rolled into the official CVS sources. -- Meta-CVS: directory structure versioning; versioned symbolic links; versioned execute permission; versioned property lists; easy branching and merging and third party code tracking; all implemented over the standard CVS command line client -- http://freshmeat.net/projects/mcvs AJ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS 1.11.5 Released strong(Security Update)/strong
CVS 1.11.5 has been released. This release fixes a major security vulnerability in CVS. The Common Vulnerabilities and Exposures project (cve.mitre.org http://cve.mitre.org) has assigned the name CAN-2003-0015 to this issue. See the text of CAN-2003-0015 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015 for more information. You may also take a look at the NEWS file http://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.112content-type=text/x-cvsweb-markup from the source distribution or go directly to the downloads page http://ccvs.cvshome.org/servlets/ProjectDownloadList. Thanks go to Stefan Esser http:[EMAIL PROTECTED] for his help on this issue! Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11.5 Released strong(Security Update)/strong
Shankar Unni wrote: CVS 1.11.5 has been released. This release fixes a major security vulnerability in CVS. The Common Vulnerabilities and Exposures project (cve.mitre.org http://cve.mitre.org) has assigned the name CAN-2003-0015 to this issue. See the text of CAN-2003-0015 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015 for more information. Looks like someone's marked the CVE entry as reserved, so we have no idea what this is about. There are literally 0 details on the CVE site, except the candidate number (not even a one-line description or the product affected). Someone care to at least summarize what the vulnerability is? The CVE data should show up soon. We were delaying update of the CVE site in order to make sure that a patch would be available before a general vulnerability announcement. Without going into too much detail, the vulnerability allows read-only CVS users to execute arbitrary code as the user the CVS server executable is running as. Again, the CVE site should be updated with more detail soon. Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -- 73. ASCII a stupid question, get a stupid ANSI! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS 1.11.5 Released strong(Security Update)/strong
CVS 1.11.5 has been released. This release fixes a major security vulnerability in CVS. The Common Vulnerabilities and Exposures project (cve.mitre.org http://cve.mitre.org) has assigned the name CAN-2003-0015 to this issue. See the text of CAN-2003-0015 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015 for more information. Looks like someone's marked the CVE entry as reserved, so we have no idea what this is about. There are literally 0 details on the CVE site, except the candidate number (not even a one-line description or the product affected). Someone care to at least summarize what the vulnerability is? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11.5 Released strong(Security Update)/strong
This security vulnerability only exists in the CVS server. CVS client builds are not affected. A corrected link to the NEWS file for this release: http://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.112.2.1content-type=text/x-cvsweb-markup Derek Derek Robert Price wrote: CVS 1.11.5 has been released. This release fixes a major security vulnerability in CVS. The Common Vulnerabilities and Exposures project (cve.mitre.org http://cve.mitre.org) has assigned the name CAN-2003-0015 to this issue. See the text of CAN-2003-0015 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0015 for more information. You may also take a look at the NEWS file http://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.112content-type=text/x-cvsweb-markup from the source distribution or go directly to the downloads page http://ccvs.cvshome.org/servlets/ProjectDownloadList. Thanks go to Stefan Esser http:[EMAIL PROTECTED] for his help on this issue! Derek ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Can I use same tag name on different branches?
I have two branches (b1 and b2) under same module. I tagged the b1 with A, and later tagged b2 with A as well. If I check out by A later, what set of files will be retrieved? Thanks a lot -Susie ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Can I use same tag name on different branches?
It wouldn't let you use the same tag on two branches without over-writting the first one, so you would end up with just the last one, in your case b2. -yared -Original Message- From: Chen, Susie Sent: Monday, January 20, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Can I use same tag name on different branches? I have two branches (b1 and b2) under same module. I tagged the b1 with A, and later tagged b2 with A as well. If I check out by A later, what set of files will be retrieved? Thanks a lot -Susie ___ 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: Can I use same tag name on different branches?
On Mon, 20 Jan 2003, Chen, Susie wrote: Date: Mon, 20 Jan 2003 16:31:48 -0800 From: Chen, Susie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Can I use same tag name on different branches? I have two branches (b1 and b2) under same module. I tagged the b1 with A, and later tagged b2 with A as well. If I check out by A later, what set of files will be retrieved? Possibly a mixture of the two, depending on how you tagged. Did you use tag or rtag? Did you use the -F option or not? Without -F, tag and rtag do not edit existing tags. But they will still apply the tag to files that don't have it. The tag command will only operate on those files that are visible in your working copy. If you are currently on branch b1, and use ``cvs tag -r b2 tagname'', then only those files which exist in both b1 and b2 (the intersection set, roughly) will be tagged. You should almost never use tag with a -r option, but use rtag instead. So, given these possibilities, you can see how the tag A might end up being spread between two branches, so that it's on the b1 branch of some files, and the b2 branch of others. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: error with checkout
Why do I get this error when attempting to checkout from a node where the repository DOES NOT reside. When I perform the same checkout from the node where the repository resides, everything is fine. cvs server: existing repository /export/cvsroot does not match /export/cvsroot/env/locke -Original Message- From: Schwenk, Jeanie Sent: Friday, January 17, 2003 12:45 PM To: CVSpost (E-mail) Subject: error with checkout I am getting one result from the node where the cvs repo resides and another when using the pserver to access the repo. Here's what I am doing on the node where the repo resides: cvs co -d . PILOT_ENV When I do the same thing from any other node, for example: cvs co -d . HOMER_ENV I get the following error: cvs server: existing repository /export/cvsroot does not match /export/cvsroot/env/homer cvs server: ignoring module HOMER_ENV Here's what is in the modules file: HOMER_ENV-d /home/sc env/homer PILOT_ENV-d /home/sc env/pilot Did I specify something incorrectly? How does using pserver make it different? What's wrong? Jeanie __ This is Linux country. On a quiet night, you can hear NT re-boot. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can I use same tag name on different branches?
On Mon, 20 Jan 2003, Demissie, Yared wrote: Date: Mon, 20 Jan 2003 16:44:56 -0800 From: Demissie, Yared [EMAIL PROTECTED] To: Chen, Susie [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Can I use same tag name on different branches? It wouldn't let you use the same tag on two branches without over-writting the first one, so you would end up with just the last one, in your case b2. If you tag twice, then CVS emits a warning for all files in which the tag exists already and leaves it alone. Suppose b2 contains a few files that are not in b1. You do cvs rtag -r b1 A module Okay, so all the files at the tip of branch b1 have the tag now. Then you do: cvs rtag -r b2 A module now any files which are present in b2, but not in b1, get the tag. There is a -F option you can use to force the retagging. I *think* that if -F is combined with -r, this will also *remove* the tags from files that are not in the new file set. I seem to recall that there is a bug with this if there is no -r option (main trunk HEAD is *implicitly* selected as the revision). Probably because the Attic optimization is applied. The workaround is to use ``rtag -F -r HEAD'' when pushing a tag forward on the main trunk, such that it's correctly removed from any files that were previously tagged, but have been removed since then. -- Meta-CVS: directory structure versioning; versioned symbolic links; versioned execute permission; versioned property lists; easy branching and merging and third party code tracking; all implemented over the standard CVS command line client -- http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: args to fchmod() and chmod()
At 11:10 2003-01-20 -0500, you wrote: Terrence Enger writes: [snip] Are you certain that it's the file type bits that are causing the problem? If so, I'd say that OS/400 is definitely *incorrect*. The When I tried fchmod() with each single bit set in the new mode, OS/400 returned an error for each value except S_IXOTH, S_IWOTH, S_IROTH, S_IXGRP, S_IWGRP, S_IRGRP, S_IXUSR, S_IWUSR, S_IRUSR, S_ISGID, S_ISUID. The file type bits came to my attention first because they caused a failure during sanity.sh. above-referenced specification says that chmod sets the SUID, SGID, sticky, and permission bits of the file to the corresponding bits in the argument. There is no requirement that non-corresponding bits of the argument be set to any particular values. Over the last several days, I have managed to read the specification both ways. (If I *really* cared, I suppose I would have to spend the ink to print that page out grin.) [snip] As per the above spec, the valid bits are precisely: (S_ISUID | S_ISGID | S_ISVTX | S_IRWXU | S_IRWXG | S_IRWXO) Well, uh, yes. But not all libraries define all these names. I have looked at all the stat.h which are readily available to me. These are OS/400 V5R1, Linux gcc 2.95.3, Mingw GCC 3.2, and Visual C++ 4.0; in each case I used the default setup for compilation. Only the Linux compiler defines all these names. OS/400 comes close, omitting only S_ISVTX. The two Windows compilers give names to the three on bits of octal 0700, but have some disagreement about what the names should be. (Sorry to seem dense, I allowed myself to be intimidated by the many differences between the platforms. On cooler consideration, most of those differences do not impact this task.) Thank you for your help. Terry. -Larry Jones Nobody knows how to pamper like a Mom. -- 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
