Checking if two versions are the same
Hi, I have a tag name, and a working directory of some project (without a sticky tag). I want to know if the tag name denotes the same version as my working directory. What is the right way to find out? Suppose that I have just checked-out this working directory (i.e. only the files from CVS are in the working directory, and I have not touched them) is the following algorithm correct? 1. Run: cvs qn update r tag-name 2. If this command had no output at all, then the tag name denotes the same as the checked-out version. If the command had output (either on stdout or on stderr), then the tag name denotes a different version. [ In any case, I would prefer a simpler solution, in which I dont need to check stderr, and preferrably even not stdout, only the exit status of a command. This is because the algorithm needs to run in several environments. ] Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: FW: Commit inconsistency: Up-to-date check did not fail though it should have !
If anyone is going to fix this, I suggest that this speed improvement is made configurable - either for the user, as a command-line option to cvs commit, or at least for the CVS administrator, e.g., as an option in CVSROOT/config. Shlomo -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2003 8:46 PM To: [EMAIL PROTECTED] Subject: Re: FW: Commit inconsistency: Up-to-date check did not fail though it should have ! On Mon, Feb 24, 2003 at 03:36:58PM +0200, Reinstein, Shlomo wrote: I have also looked up the sources of CVS. In commit.c, there's the following comment: (I'm quoting) /* Sending only the names of the files which were modified, added, or removed means that the server will only do an up-to-date check on those files. This is different from local CVS and previous versions of client/server CVS, Yikes; I had no idea! That does seem pretty conclusive, though :-/ but it probably is a Good Thing, or at least Not Such A Bad Thing. */ I'd sure like to know *why* he felt that. The commit message (src/commit.c rev 1.40) is no more revealing than the comment. I imagine the change was made as a speed improvement, but that doesn't seem sufficient grounds for the resulting violation of user expectations -- at least, not without more justification than was given. I just wonder how come this does not cause problems in the development of large projects that are kept in CVS. So do I! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ 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
FW: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
I've just compiled and tried CVS 1.11.5 -- same behavior. Up-to-date check does not work correctly when using client/server. Shlomo -Original Message- From: Reinstein, Shlomo Sent: Sunday, February 23, 2003 12:49 PM To: Guus Leeuw jr. Cc: [EMAIL PROTECTED] Subject: RE: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! This happened with 1.10.8 and also with 1.11.1p1. No related fix has been mentioned in the news file for CVS versions 1.12-1.15. Shlomo -Original Message- From: Guus Leeuw jr. [mailto:[EMAIL PROTECTED] Sent: Sunday, February 23, 2003 12:07 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: AW: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Shlomo, Which version was this? 1.11.5? Or the older version? Cheers, Guus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Reinstein, Shlomo Gesendet: zondag 23 februari 2003 9:24 An: Eric Siegerman; [EMAIL PROTECTED] Betreff: RE: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Hi, I have ran the test with the repo local to the CVS server, and it shows the same behavior. Which brings me to the conclusion that the client/server protocol does not function as expected. Here's the scenario: (Can be done by the same user on the same machine) [ rest snipped ] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 13/02/2003 ___ 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
FW: Commit inconsistency: Up-to-date check did not fail though itshould have !
I have also looked up the sources of CVS. In commit.c, there's the following comment: (I'm quoting) /* Sending only the names of the files which were modified, added, or removed means that the server will only do an up-to-date check on those files. This is different from local CVS and previous versions of client/server CVS, but it probably is a Good Thing, or at least Not Such A Bad Thing. */ So it seems like this behavior was intentional. I'm sure you realize the consequences of this. I just wonder how come this does not cause problems in the development of large projects that are kept in CVS. Is there an intention to fix (/change) this? Shlomo -Original Message- From: Reinstein, Shlomo Sent: Monday, February 24, 2003 1:49 PM To: [EMAIL PROTECTED] Subject: FW: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! I've just compiled and tried CVS 1.11.5 -- same behavior. Up-to-date check does not work correctly when using client/server. Shlomo -Original Message- From: Reinstein, Shlomo Sent: Sunday, February 23, 2003 12:49 PM To: Guus Leeuw jr. Cc: [EMAIL PROTECTED] Subject: RE: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! This happened with 1.10.8 and also with 1.11.1p1. No related fix has been mentioned in the news file for CVS versions 1.12-1.15. Shlomo -Original Message- From: Guus Leeuw jr. [mailto:[EMAIL PROTECTED] Sent: Sunday, February 23, 2003 12:07 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: AW: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Shlomo, Which version was this? 1.11.5? Or the older version? Cheers, Guus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Reinstein, Shlomo Gesendet: zondag 23 februari 2003 9:24 An: Eric Siegerman; [EMAIL PROTECTED] Betreff: RE: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Hi, I have ran the test with the repo local to the CVS server, and it shows the same behavior. Which brings me to the conclusion that the client/server protocol does not function as expected. Here's the scenario: (Can be done by the same user on the same machine) [ rest snipped ] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 13/02/2003 ___ 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
RE: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
Hi,
I have ran the test with the repo local to the CVS server, and it shows the
same behavior. Which brings me to the conclusion that the client/server
protocol does not function as expected. Here's the scenario: (Can be done by
the same user on the same machine)
1. Create the repository:
cvs -d :ext:usernameserver:path-to-repository init
2. Create a test project: ('proj')
mkdir temp
cd temp
echo nonsense1 a
echo nonsense2 b
cvs -d :ext:usernameserver:path-to-repository import -m New repo
proj dummy v1
cd ..
3. Get 2 working copies:
mkdir w1
cd w1
cvs -d :ext:usernameserver:path-to-repository get proj
cd ..
mkdir w2
cd w2
cvs -d :ext:usernameserver:path-to-repository get proj
cd ..
4. Modify two different files in the two working copies and commit them:
cd w1/proj
echo morenonsense a
cvs ci
cd ../../w2/proj
echo morenonsense b
cvs ci
You'll see that despite the fact that w2/proj is not up-to-date, the commit
will succeed.
5. See that both copies are actually not up-to-date:
cd ../..
cd w1/proj
cvs status b
cd ../../w2/proj
cvs status a
Shlomo
-Original Message-
From: Eric Siegerman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 18, 2003 10:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Commit inconsistency: Up-to-date check did not fail though it
sho uld have !
On Tue, Feb 18, 2003 at 08:37:12PM +0200, Reinstein, Shlomo wrote:
I also checked that this strange behavior was not fixed in CVS 1.11.1p1.
I
don't know about the newer versions (e.g., 1.15.1), I will check this as
well.
Darn! I was really hoping that was it. Well, maybe it's fixed
in 1.11.5, but this new data point makes me less hopeful of that.
What's wrong with the repository being on NFS?
Larry summed that up admirably.
Since you have a small reproducible test, could you try it with
the repo *not* NFS-mounted, but local to the CVS server? Even if
it still fails (as I half-suspect it will), at least we can stop
harping on the NFS thing and look elsewhere :-) So whichever the
outcome, it won't have been wasted effort.
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
- Leslie Lamport
Or has an NFS implementation that won't interoperate with mine.
- me
___
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: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
This happened with 1.10.8 and also with 1.11.1p1. No related fix has been mentioned in the news file for CVS versions 1.12-1.15. Shlomo -Original Message- From: Guus Leeuw jr. [mailto:[EMAIL PROTECTED] Sent: Sunday, February 23, 2003 12:07 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: AW: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Shlomo, Which version was this? 1.11.5? Or the older version? Cheers, Guus -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Reinstein, Shlomo Gesendet: zondag 23 februari 2003 9:24 An: Eric Siegerman; [EMAIL PROTECTED] Betreff: RE: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Hi, I have ran the test with the repo local to the CVS server, and it shows the same behavior. Which brings me to the conclusion that the client/server protocol does not function as expected. Here's the scenario: (Can be done by the same user on the same machine) [ rest snipped ] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.455 / Virus Database: 255 - Release Date: 13/02/2003 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
The recursive behavior of CVS
Hi, About 2 years ago I asked about the recursive behavior of CVS. I asked how CVS decides whether it should recurse into a subdirectory or not, and I got the following reply from Larry Jones: In general, if there's no CVS subdirectory in a directory or if there are no D lines in CVS/Entries, CVS will recurse into all of the existing subdirectories. If there are D lines in CVS/Entries, CVS will recurse into only those subdirectories. You can find the question and the reply at: http://www.mail-archive.com/info-cvs@gnu.org/msg07004.html Is this behavior limited to a single CVS repository? That is, if I have a directory tree that contains working directories from several repositories, and also non-working directories, is this algorithm still the same? I have the following case: Under some directory (let's call it root), there are 4 directories: dir1, dir2, dir3, dir4. dir1 and dir4 are working directories, while the other two are non-working directories (just simple directories created with mkdir), however, they contain working directories just beneath them. When I run cvs update at root, it recurses into dir1 and dir4, but not into dir2 and dir3 (i.e., not into their subdirectories which are working directories). Any idea why is that? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Commit inconsistency: Up-to-date check did not fail though it should have !
Hi, I've always trusted CVS to do its work well, but today for the first time I found out that it doesn't. The problem might not be in CVS itself, but it's a very basic thing in CVS that does not work. The scenario is as follows: - User A checks-out the latest version of project p. - User B checks-out the latest version of project p. - User A changes one of the files in p, and commits his changes to the repository. - User B changes one of the files in p (not the same file that user A changed). - User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. Technical details: - User A works on Linux, using CVS client server version 1.10.8. - User B works on Windows 2000, using CVS client 1.10.7 and server 1.10.8 (both users using the same CVS server machine, same version of CVS on both machines) - The repository is on NFS. Any idea? Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Commit inconsistency: Up-to-date check did not fail though it sho
No, B had done a cvs commit without specifying the files to commit on the command-line. This is why it is so suprising for me. CVS with a local repository does not let such commits take place, but the client/server does. Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 5:38 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: Re: Commit inconsistency: Up-to-date check did not fail though it sho Reinstein, Shlomo writes: - User A checks-out the latest version of project p. - User B checks-out the latest version of project p. - User A changes one of the files in p, and commits his changes to the repository. - User B changes one of the files in p (not the same file that user A changed). - User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. CVS only demands that what you're committing be up to date. If B had done a simple cvs commit, then CVS would have examined the entire directory and complained about the file modified by A being out of date. Instead, B apparently commited just the file he had modified (cvs commit foo), so CVS only checked that file, found it up to date, and allowed the commit. -Larry Jones See, it all makes sense. See? See?? They never see. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
This would be fine if CVS had consistent behavior when using a local repository and when using client/server. Until a short time ago, we used to work with a local repository (on a network drive), and we got used to that behavior. Our set of scripts around CVS rely on this behavior. Shlomo -Original Message- From: Brandon Craig Rhodes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 3:52 PM To: [EMAIL PROTECTED] Subject: Re: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! Reinstein, Shlomo [EMAIL PROTECTED] writes: - User A checks-out the latest version of project p. - User B checks-out the latest version of project p. - User A changes one of the files in p, and commits his changes to the repository. - User B changes one of the files in p (not the same file that user A changed). - User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. I believe that this behavior is intentional - CVS places on the programmer responsibility for knowing which files must remain in some consistent state in committed revisions of the project. The problem with CVS attempting to prevent this situation manually is that CVS, which in its defense knows very little about the meaning of your project's file's organization, does not know which files need to be updated before allowing user B to commit. In our project, for example, it would be sufficient before committing this_module.sql to make sure that this_module.test.py (its test suite) was up-to-date as well. In another project CVS might need to check that the entire current working directory were up-to-date before committing; and in your case perhaps the parent directory and its sub-directories need to become involved as well. Instead, all of this is probably best done with a simple CVS that knows only about updating and committing things, and developers who supplement CVS's default behavior with scripts that support their project's correctness. -- Brandon Craig Rhodes http://www.rhodesmill.org/brandon Georgia Tech [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
RE: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
I've also been very surprised by this behavior, having used CVS for a couple of years now, as an admin of our CVS repository. I was able to generate a tiny example that demonstrates this behavior, even for a single user working on the same project, in two different working directories (and using the same client machine and same server machine in both). I made a change in working directory A, committed it, and at the time made a change to another file in working directory B and was able to commit it without updating first. After the commit in B, cvs status shows that the file I committed from A needed patch, and vice versa. I even did that on a newly created repository which contained only the small project that I just created. I also checked that this strange behavior was not fixed in CVS 1.11.1p1. I don't know about the newer versions (e.g., 1.15.1), I will check this as well. Yes, the CVS server box is the only computer that accesses the repository directly. All use the same CVS server box. I've also tried using different server machines to verify that the problem was not with the specific CVS server box we were using, and the same behavior happened in the other server machines as well. What's wrong with the repository being on NFS? Isn't that the case with most CVS repositories? I didn't know there can be problems between an NFS client and server being on different platforms, but I bet that the machine on which the repository is located is also a Linux machine. Shlomo -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 7:16 PM To: [EMAIL PROTECTED] Subject: Re: Commit inconsistency: Up-to-date check did not fail though it sho uld have ! On Tue, Feb 18, 2003 at 06:35:35PM +0200, Reinstein, Shlomo wrote: This would be fine if CVS had consistent behavior when using a local repository and when using client/server. Until a short time ago, we used to work with a local repository (on a network drive), and we got used to that behavior. Our set of scripts around CVS rely on this behavior. It's supposed to work as you expect, locally and client/server both. I'm very surprised by the behaviour you saw -- so surprised that I can't help suspecting that something else was going on, since I don't believe I've ever seen an up-to-date check pass when it shouldn't. Technical details: - User A works on Linux, using CVS client server version 1.10.8. - User B works on Windows 2000, using CVS client 1.10.7 and server 1.10.8 (both users using the same CVS server machine, same version of CVS on both machines) Umm, those are pretty old! May I suggest upgrading to 1.11.5? No guarantee that it'll help, but it couldn't hurt. - The repository is on NFS. You probably know which red flag that's raising for me :-) But from what you say above, it sounds as though only the one CVS-server Linux box is accessing the repo directly (i.e. it's the only NFS client to touch it). If that's correct, it makes things less worrisome -- but I suppose there still might be interoperability problems between the Linux NFS client and your NFS server if it's on a different platform. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ 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: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
Reinstein, Shlomo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... - User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. User B is an idiot for not performing a commit over the entire tree which is affected by his change, and for having unrealistic expectations on what a single-file commit ought to do. Why rush into conclusions? User B did perform a commit over the entire tree, which is why I am reporting this on the mailing list. Just go to the highest relevant directory and type ``cvs ci'' with no arguments, or at most a -m to specify the message. In Meta-CVS, if you do a ``mcvs ci'' with no arguments anywhere in the tree, it will commit on the entire project, directory structure, files and all. The tag and update commands work similarly. We don't use meta-CVS, but we have a Perl wrapper around CVS. One of the things this wrapper does is disable commits from anywhere inside a project. Users are only allowed to commit from the top level directory of a project. The only way to say ``commit (or update or tag) this directory only'' is to specify the single parameter . The other commands like log and diff work just on the current directory and its subdirectories when no arguments are given. Same with our Perl wrapper. This design is deliberate; it promotes consistency. If you make it awkward for people to achieve consistency---by for instance forcing them to ``cd'' to some higher directory to do a commit---they will fail to do so, at least some fraction of the time. They don't have a choice... They cannot fail to do so. - The repository is on NFS. In related news, user B's CVS administrator is also an idiot. And why is that? ___ 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: Finding which tags exist without checking-out
We're using CVS 1.10.7. This probably means that the rlog implementation changed in a newer version, even though my version says this command is deprecated. Since I am really not interested in anything but the tags themselves, is there something like rstatus -v, or do I have to get all the log information and filter it (like you show below)? Shlomo -Original Message- From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 09, 2003 7:10 PM To: [EMAIL PROTECTED] Subject: Re: Finding which tags exist without checking-out On Sun, Feb 09, 2003, Reinstein, Shlomo wrote: Running cvs rlog gives: cvs log: warning: the rlog command is deprecated cvs log: use the synonymous log command instead cvs log: cannot open CVS/Entries for reading: No such file or directory cvs [log aborted]: no repository Hmmm... works fine for me: | $ cvs -d [EMAIL PROTECTED]:/e/ossp/cvs rlog ossp-pkg/pth/ChangeLog | head -20 | RCS file: /d1/e/ossp/cvs/ossp-pkg/pth/ChangeLog,v | head: 1.604 | branch: | locks: strict | access list: | symbolic names: | PTH_2_0b2: 1.603 | PTH_2_0b1: 1.598 | PTH_2_0b0: 1.591 | PTH_1_4: 1.557.0.2 | PTH_1_4_1: 1.557 | PTH_1_4_0: 1.545 | PTH_1_3_7: 1.488.2.10 | PTH_1_4a3: 1.523 | PTH_1_3_6: 1.488.2.9 | PTH_1_4a2: 1.518 | PTH_1_3_5: 1.488.2.7 | PTH_1_4a1: 1.505 | PTH_1_3_4: 1.488.2.6 This is with CVS 1.11.5. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ 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
Finding which tags exist without checking-out
Hi, Suppose I would like to find out which tags a module has, _without_ first checking it out. Can this be done? If so, how? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Specifying options for ssh
Hi, I'm using the :ext: access method of CVS, with CVS_RSH set to ssh2. Is there a way to specify options for the rsh replacement? I noticed that setting CVS_RSH to ssh2 -x, for example, does not work: CVS says: Cannot exec ssh2 -x. Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Finding which tags exist without checking-out
Running cvs rlog gives: cvs log: warning: the rlog command is deprecated cvs log: use the synonymous log command instead cvs log: cannot open CVS/Entries for reading: No such file or directory cvs [log aborted]: no repository Shlomo -Original Message- From: Ralf S. Engelschall [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 09, 2003 4:25 PM To: [EMAIL PROTECTED] Subject: Re: Finding which tags exist without checking-out On Sun, Feb 09, 2003, Reinstein, Shlomo wrote: Suppose I would like to find out which tags a module has, _without_ first checking it out. Can this be done? If so, how? You can run cvs rlog before cvs checkout to see the existing tags. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ 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
Problems with the :server: access
Hi, We are using the :server: access method to access our CVS repository. Trying to check-out a module, one of my users got the following message: warning: unrecognized response `text' from cvs server (where 'text' is some arbitrary string.) I figured out that 'text' was actually printed from the ~/.cshrc file on the server. The ~/.cshrc file of the user printed a few things to the standard output (e.g., echo $PATH or printing some special characters that change the title of the xterm window) and these things got back to the CVS client as an unregcognized response from cvs server. Most of these things ended in a warning message like the above but some of them also caused erroneous conflicts to occur. What is wrong here, and what can the user do to fix it? Is it a server configuration problem (is the .cshrc restricted not to print on stdout) or a client configuration problem? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: check_cvs.pl script
Thanks, Donald, but I didn't mean to get an updated private version. I really meant to ask if this script is going to be published (e.g., in the contrib/ directory) and regularly updated. One thing I'd add to the script is read the checkoutlist file and avoid reporting the files specified there as files that do not belong in the repository. Shlomo -Original Message- From: Donald Sharp [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 2:57 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: Re: check_cvs.pl script Attached. Documentation inside the script. donald On Thu, Nov 21, 2002 at 08:29:18AM +0200, Reinstein, Shlomo wrote: Hi, I found the check_cvs.pl script in some of the messages in the mailing-list. Is this script published formally somewhere, or is that a private script that was provided only for the cases in those messages? Shlomo ___ 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
check_cvs.pl script
Hi, I found the check_cvs.pl script in some of the messages in the mailing-list. Is this script published formally somewhere, or is that a private script that was provided only for the cases in those messages? Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stale CVS locks
Hi, Back to the network-mounted repository issue after a long time. See Larry's reply below. What is wrong with accessing a repository from Windows using :local:, when the repository is mapped to a drive letter (using Samba)? Recently we get many problems of the form: cvs [tag aborted]: cannot rename file //,filename, to z:\...\filename,v: File exists I assume this is because of the network-mounted repository, but I don't understand the reason for these problems. Can anyone explain this? Also, do these problems never happen in a Linux client which accesses the repository with :local:? Thanks, Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:larry.jones;sdrc.com] Sent: Tuesday, June 12, 2001 9:03 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Stale CVS locks I'd like to know, is there a common way of handling these problems? If not, can you recommend us how to deal with this? If don't know if it matters for this problem, but we're using CVS (the same repository) from both Windows and Linux, and we're not using the client/server model of CVS (and we can't start using this model now). The Ctrl+Break case may perhaps be solved by capturing those keystrokes, but there may be other reasons for stale CVS locks such as when a machine crashes, so I think this problem should be solved more generally. The problem occurs so rarely in practice (at least on Unix-like systems) that removing the stale locks manually has been a perfectly reasonable way to address the problem. It sounds like you're using a network- mounted repository (Samba?), which is practically begging for trouble, so you shouldn't be surprised that you're finding it. You really should switch to client/server CVS -- why do you say you can't? -Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Order of operations during commit when using a CVS server
Hi, Until now, I've been using CVS with a locally-mounted repository. When I did cvs commit, it used to first run the command specified in CVSROOT/commitinfo for every directory that had to be committed, and then it launched the editor to enter the log message (only if the commands had a good exit value for all directories). Now, I am using a CVS server, and that behavior is reversed: CVS first launches the editor so that I can enter a log message, and only afterwards it runs the command from the CVSROOT/commitinfo. The result is that I sometimes find that I entered the log message for nothing, because as soon as I exit the editor, it fails because of the commands in CVSROOT/commitinfo. Is this a CVS bug, or am I doing something wrong? (I am also the owner and admin of the repository on the server.) Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs commit features
It doesn't have to be so bad if it takes care of your ignore settings as well. I think such an option may be good, at least for someone who did a large re-org of the files in the project. However, I agree with Greg A. Woods that the place of such options is not CVS itself but rather wrappers of CVS or GUIs. Shlomo -Original Message- From: Mike Ayers [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 8:48 PM To: Reinstein, Shlomo Cc: '[EMAIL PROTECTED]' Subject: Re: cvs commit features Reinstein, Shlomo wrote: Of course, a user can always use cvs add and cvs remove to add or remove files, but these two options can help him/her make sure they didn't forget to do this for some of the files. This is one of those things that might work really well, but only for certain development models. For instance, I am using a GUI based tool. It likes to create lots of files that may or may not need to be archived. I have experimentally determined that if I archive a certain set of them, then there seems to be no problems. Do I want CVS to pester me about the ones I'm not archiving every time I do a commit in that directory? No way! And just think what would happen if you inadvertently did your CVS commit without making clean first... Nannyware sucks. Optional nannying? Hmmm - doesn't the nannyware model *require* that the nagging not be optional? /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs commit features
Hi, We have written a set of Perl scripts that wrap around CVS commands and do some more stuff that is specific to our working environment. Someone suggested that I add two options to the wrapper for cvs commit, and I was wondering if anyone has thought about adding these two options to CVS itself or to a GUI for CVS, or otherwise, if there are any problems with these options: 1. An option to make commit ask you if you'd like to get rid of files that exist in the repository but not in your working directory, and possibly specify on the command-line which files to remove (or have the commit ask you for each file or for each file extension). 2. An option to make commit ask you if you'd like to add files that exist in your working directory but not in the repository, and possibly specify on the command-line which files to add (or have the commit ask you for each file or for each file extension). Of course, a user can always use cvs add and cvs remove to add or remove files, but these two options can help him/her make sure they didn't forget to do this for some of the files. Thanks a lot, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS bug? Committing a new file to a branch failed and the local file was cleared!
Hi, A user checked-out a CVS project from a branch, modified it, added a file, and then tried to commit. When he committed, he saw output like the following: (I deliberately changed the names of the files and paths, note the problem with file2.c below) ... repository-path/Proj/file1.c,v -- file1.c new revision: 1.5.2.1; previous revision: 1.5 done RCS file: repository-path/Proj/Attic/file2.c,v done cvs commit: cannot remove file2.c: Permission denied cvs [commit aborted]: cannot rename file CVS/,,file2.c to file2.c: File exists C:\working-directory cvs status Proj/file2.c === File: file2.c Status: Locally Added Working revision:New file! Repository revision: No revision control file Sticky Tag: branch_v82 - MISSING from RCS file! Sticky Date: (none) Sticky Options: (none) Looking at the repository, file2.c,v exists, and it has some admin information but no contents (trying to do co file2.c,v to a temporary directory yields a 0-size file). Also, the local copy of this file (from which it was committed) has been cleared. The local file still exists, but has the size 0. Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS bug? Committing a new file to a branch failed and the local f ile was cleared!
The user was working in Windows 2000, CVS version 1.10.7. The keyword expansion is a good point - I now understand why a commit operation changes the local copy of the file. This is problematic, though - because the user was left with an empty file - both locally and in the repository, and there was no way to restore it; you must be right that CVS should first commit the file and only then modify the local copy, even just to prevent such cases. Thanks, Shlomo -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 8:04 PM To: '[EMAIL PROTECTED]' Subject: Re: CVS bug? Committing a new file to a branch failed and the local f ile was cleared! On Tue, Jul 30, 2002 at 11:52:44AM +0300, Reinstein, Shlomo wrote: cvs commit: cannot remove file2.c: Permission denied cvs [commit aborted]: cannot rename file CVS/,,file2.c to file2.c: File exists These are the key. (Especially the first one; the second error just confirms which copy of file2.c the first error occurred on.) CVS was trying to replace the sandbox copy of the file with another copy it had created, and was unable to do so. (I don't know why it wanted to do this; since it hadn't yet committed a revision, it seems too early to have been doing keyword expansion. But that's immaterial; what matters is that it tried, and failed.) Now, as to why it failed. The error is Permission denied. You don't say which operating system, (or, for that matter, which CVS version). If the sandbox lives on a UNIX machine, then the problem would appear to be that the user has no write permission in file2.c's parent directory. How the user created the file in the first place, I'm not sure. Maybe the directory was chmod'ed afterward? Maybe it's chmod'ed like /tmp on many systems -- drwxrwxrwt -- and owned by someone other than the user in question? Dunno, but that's a simple UNIX thing. If the sandbox is on an NT machine (or worse, if it's on a remote-mounted file system of some sort), I can't offer any further thoughts. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ 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
Automatically tagging the repository after (almost) every commit
Hi, Our users use CVS indirectly through a Perl script that I wrote. This Perl script provides the same command and the same options as CVS, with few additions. For commit, the script also (by default) tags the repository when the commit is over, and it has an additional option to avoid tagging the repository. The tag that it creates is composed of the current date time, and the 1st line of the user's commit message (formatted in such a way that it will fit a tag name). In order to get the 1st line of the commit message, there's another script that runs using the CVSROOT/loginfo file, and writes the commit message to some file that is later read by the first script. That file is created in a directory specified by an environment variable, and the name of that file consists of the name of the machine and the process id of the Perl script (passed to the loginfo script using an environment variable), to distinguish it from any other commit. Can I achieve the same if the repository sits in a CVS server? If so, how? I realize that I can use rtag in the loginfo script to tag the repository, knowing the 1st line of the commit message. But I don't know whether or not I should tag the repository - this information is only in the first Perl script. Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Automatically tagging the repository after (almost) every commit
I have thought of that solution. The problem is, of all log messages in all files of the project, how do I find the log message that the user just wrote? Note that the commit could be made to a branch or to the trunk. I can easily find out what the branch is, but the log message only appears in those files that have actually been committed. I can, of course, check which files are to be committed, just before the committed - but I prefer to use a simpler method to achieve what I wanted, if possible. Shlomo -Original Message- From: Jouni Heikniemi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 11:47 AM To: Reinstein, Shlomo Cc: '[EMAIL PROTECTED]' Subject: Re: Automatically tagging the repository after (almost) every commit On Wed, 17 Jul 2002, Reinstein, Shlomo wrote: Can I achieve the same if the repository sits in a CVS server? If so, how? I realize that I can use rtag in the loginfo script to tag the repository, knowing the 1st line of the commit message. But I don't know whether or not I should tag the repository - this information is only in the first Perl script. First, I'd question the need for that kind of tagging, but I hope you really know it's the best way to achieve whatever you're doing :-) I think you don't want to imagine (much less implement) the solution that it would take to get all those params etcetera to the loginfo script, so I suggest you start implementing all the tagging logic into the perl wrapper your users are running. Try doing a `cvs log` after the commit has finished, pick up the proper log message and then compose a tag. That way you wouldn't have to hook the loginfo for this purpose at all. Jouni ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: binary vs. text files
Hi, You can type cvs status filename, and look for Sticky Options: in the output. If -kb is the value there, then the file is stored as binary. Otherwise, it is stored as text. About changing file status: http://www.cvshome.org/docs/manual/cvs_9.html#SEC80 Please note that the sticky options are per file, not per revision, which means that if you change the status to binary or text, it will effect all revisions of the file. Shlomo -Original Message- From: Dusan Juhas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 1:11 PM To: [EMAIL PROTECTED] Subject: binary vs. text files Hello, is there a cvs command which can determine if a file is stored as binary/text? Can I change file status from text to binary (and vice versa) during his life in the repository? If so, how it can be done? Thank you. -- Best regards, Dusan Juhas ___ 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: Automatically tagging the repository after (almost) every commit
I also thought of that, but this is complicated: 1. I need to check which directories should be committed, since I have to allow a different log message for each directory (like in CVS). 2. I need to launch an editor; and I have to support both Windows and Linux, and several shell types. Therefore I prefer to let CVS ask for what it needs. Shlomo -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 7:44 PM To: '[EMAIL PROTECTED]' Subject: Re: Automatically tagging the repository after (almost) every commit On Wed, Jul 17, 2002 at 11:47:11AM +0300, Jouni Heikniemi wrote: Try doing a `cvs log` after the commit has finished, pick up the proper log message and then compose a tag. Or prompt for the log message yourself, and pass it to CVS with -m. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ 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
Error in commit_prep.pl?
Hi, I think there's a bug in commit_prep.pl (in the contrib/ directory), that prevents committing the merge result of merging an existing branch with a new one from the same version. Please let me know what you think: At some point, I created a branch (b1) from the latest trunk version (let's call this latest version x). I made some check-ins to b1, and changed a file named a.c. At a later time, I created a new branch (b2) from the latest trunk version (which is newer than x), but a.c was not modified between x and now. I made some check-ins to b2, but not to a.c. Then, I merged b1 into b2, and wanted to commit. commit_prep.pl prevented me from doing so: a.c - How dare you!! You replaced your copy of the file 'a.c', which was based upon version 1.45, with an newer version based upon 1.45.2.1. Please move your 'a.c' out of the way, perform an update to get the current version, and them merge your changes into that file. Isn't that a bug? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Communicating client information to the CVS server
Hi, When working with a CVS server, is there a way to communicate non-CVS related information from the client to the server (and vice versa)? Let me explain what I would like to do. First some short background: We have a system (made mostly of Perl scripts) that uses CVS for the source control operations, but adds some functionality to it, as needed by our development methodology. Our users do not run cvs directly, but rather they use our system, which in turns runs cvs to execute the commands. Our system has a special shell, in which many environment variables are defined, and all work with the system is done from within that shell. commit is one of the operations in which our system extends the functionality of CVS. The system checks a few pre-conditions, and only if those pre-conditions are met, it calls cvs commit. During the commit, log information is collected using the CVSROOT/commitinfo and CVSROOT/loginfo files, and when the commit is over, the system makes use of this log information. The pre-conditions checked by our system for commit have are not related to the files to be committed; the system checks for the existence of some files, both inside and outside the working directory. While it's simple to check for them in the system, it is impossible to check for them in the pre-commit script, which runs in a new process, and in the case of the CVS server, even on a different machine in a completely different environment. In order for the pre-condition checking to work, I need to disable check-ins using cvs commit, and enable check-ins only using our system. Currently, we have a locally-mounted repository (we don't yet use client/server), and I make the distinction between cvs commit and our system by checking for the existence of some environment variable in the pre-commit script (which runs by CVSROOT/commitinfo). The system sets this variable before calling cvs commit; the users are not aware of this. If this environment variable does not exist, then the pre-commit script knows that the user ran cvs commit and exits with an error exit status. How can a similar thing be done with client/server? In the other direction - the post-commit script (which runs by CVSROOT/loginfo) collects some information in a file, and then the system reads this file when the commit is over. How can I achieve that with a client/server model? Thanks in advance, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Moving/renaming working directories
Hi, Suppose I check-out a project from the CVS repository, and later I move the working directory to another location on my hard drive (together with the CVS/ subdirectory, of course). Can I encounter problems running CVS commands from the new location of the working directory? Or it is totally safe to do so? (Let's also mention that I move the working directory to a location which did not have anything checked-out under it before, so the parent directory in the new location does not have a CVS/ subdirectory.) Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to find out the CVSROOT and location in the repository of a w orking directory
About the first possibility below, this was the first thing that I tried before I sent the message to the mailing list. I noticed that I have a problem with sticky dates: I cannot take the sticky date from the output of cvs status and just use cvs update -D sticky-date. I need to do a format conversion, and moreover, I need to translate the timezone! I preferred not to use the 2nd option because then I would need to add support for each OS/shell. (The copy command would be different.) Just FYI, I am no longer interested in a solution for this because I am now taking a different approach to my problem, which avoids the need in any CVS operations. However, I have learned a few very valuable and interesting things during this discussion... Thanks, Shlomo -Original Message- From: Eric Siegerman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 1:31 AM To: '[EMAIL PROTECTED]' Subject: Re: How to find out the CVSROOT and location in the repository of a w orking directory To be more specific about what I need (maybe there's a way to do it without caring for the CVSROOT and location), I have a file in each module that has a fixed name and is used by my script to enable users to lock the module for a short time. Whenever a new branch is created for a module, this file should be initialized for that branch, to indicate that the branch is not locked. To do this, the script should modify it and commit a new revision of it into the branch. (This is needed because the file might indicate locked state for the root of the branch.) In order to do this, I want to check-out a fresh copy of that file (okay, with its whole directory) to a temporary directory, and then do these things on the copy in the temporary directory. In order to check it out, I need the CVSROOT and location within the repository. Three possibilities: 1. Do this in place, without using a temporary directory: - use cvs status lock-file (no -t needed) to learn which is the sticky branch or date for the file, if any - use cvs update -r new-branch lock-file to put the lock file onto the correct branch - make your changes, and commit - use cvs update -C (and either -D/-r or -A) to restore the lock file to its previous state 2. Use the temporary directory, but copy it from the working directory rather than checking it out fresh. - Use something like this shell pseudocode to set up the temporary directory: cd working-dir mkdir /tmp/foo$$ cp -pR lock-file CVS /tmp/foo$$ (Note that we only copy the lock file itself, not the rest of the directory's contents.) - Make your changes to the temporary copy - Commit. You'll have to name the file explicitly: cvs commit lock-file Otherwise the up-to-date check will fail, because all the other files in the (temporary) working directory will be missing. 3. As Larry Jones says, give in and use CVS/Root and CVS/Repository. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Anyone who swims with the current will reach the big music steamship; whoever swims against the current will perhaps reach the source. - Paul Schneider-Esleben ___ 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
cvs release does not update the CVS/Entries(.log) file
Hi, I would like to use cvs release to get rid of a sub-tree of my project. However, I noticed that cvs release does not update the CVS/Entries (or CVS/Entries.log) file, which causes a problem later when I want to run other commands, like cvs status, cvs tag, etc. For example: cvs -d my-cvs-root get my-project ... the directory tree is checked-out ... cd my-project cvs release -d sub-dir You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `sub-dir': y cvs tag cvs tag: Tagging . ... tags some files and directories ... cvs tag: Tagging sub-dir cvs [tag aborted]: could not chdir to sub-dir: No such file or directory I think that if cvs get adds sub-directories to the CVS/Entries file, then cvs release should remove them from that file. Otherwise, is there a clean way to get rid of a sub-tree which is not needed and continue working on the rest of the project in the working directory? Note that the same thing happens if sub-dir is not part of my-project, but after checking-out my-project I change directory to it and then check-out sub-dir explicitly (from another location in the repository or even from a different repository) - it still adds sub-dir to the CVS/Entries file of my-project. Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How to find out the CVSROOT and location in the repository of a w orking directory
Hi,
In my question, I was referring ONLY to the CVSROOT (and repository
location) of a working directory. Inside a working directory, the
information is stored in the CVS/Root and CVS/Repository files, and the
CVSROOT environment variable is not at all interesting (because it is
overriden by the CVS/Root file).
Like I said, I could read the CVS/Root file, but I consider this file to be
CVS internals, and thus reading it is not a clean solution (that is, I
would have to change my script if the implementation of CVS changed and this
file was renamed, for example).
I got another answer that said to run cvs -t status (use the global -t
option). The problem with this, as far as I'm concerned, is that the CVSROOT
information from the -t option goes to the standard error, rather than the
standard output.
Thanks,
Shlomo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 3:27 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: How to find out the CVSROOT and location in the repository
of a w orking directory
Shlomo,
You could have your perl program check the environment for CVSROOT as shown
here:
my $CVSROOT = $ENV{'CVSROOT'};
if ($CVSROOT eq ) {
print CVSROOT is not defined - aborting\n;
exit 1;
}
If you are using pserver you could remove the pserver information using:
$CVSROOT =~ s/^.*:(.*)$/$1/;# remove any pserver stuff
You could also check the CVS/Root file at the first directory in a work
area. The content of it should match CVSROOT.
Dale Miller
-Original Message-
From: Reinstein, Shlomo [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 23, 2002 9:11 AM
To: '[EMAIL PROTECTED]'
Subject: How to find out the CVSROOT and location in the
repository of a w orking directory
Hi,
Is there a clean way to find out what is the CVSROOT of a working
directory and where in the repository it is located? I need
to find that out
from within a Perl script, and by clean I mean that I
prefer not to look
into the CVS/Root and CVS/Repository files, because I
consider them to be
CVS internals that might change some day.
I know that using cvs status I can find out the whole
repository path, but
there is no separation between the CVSROOT and the location inside the
repository.
To be more specific about what I need (maybe there's a way to
do it without
caring for the CVSROOT and location), I have a file in each
module that has
a fixed name and is used by my script to enable users to
lock the module
for a short time. Whenever a new branch is created for a
module, this file
should be initialized for that branch, to indicate that the
branch is not
locked. To do this, the script should modify it and commit a
new revision
of it into the branch. (This is needed because the file might indicate
locked state for the root of the branch.) In order to do
this, I want to
check-out a fresh copy of that file (okay, with its whole
directory) to a
temporary directory, and then do these things on the copy in
the temporary
directory. In order to check it out, I need the CVSROOT and
location within
the repository.
Thanks,
Shlomo
___
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: How to find out the CVSROOT and location in the repository of a w orking directory
Thanks for the detailed reply!
Before this sample script, I actually thought that your idea was bad because
every type of shell or operating system has its own way of redirecting the
standard error -- but you proved me wrong (or is it Perl that always
launches the same type of shell when it runs backticks, and this is why it
works?). I really didn't know that this error redirection is uniform in all
shells and operating systems. (At least those we use, Linux and Windows with
several shells in each.) I was surprised to see that this worked on both
cmd on Windows, and on tcsh and bash on Linux.
Thanks!
Shlomo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 4:51 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: How to find out the CVSROOT and location in the repository
of a w orking directory
Shlomo,
If the CVS internals change for CVS/Root and CVS/Repository many people
would be changing scripts.
The global -t tag suggestion could be used. You are correct that the
output goes to STDERR but you could redirect STDERR to STDOUT (21) as
shown in this example program:
--
#!/usr/local/bin/perl -w
$file = no_such_file;#use non existing file
@result = `cvs -t status $file 21`;
print DEBUG1: \@result=\n @result\n;
($cvsroot) = grep { s/.*main loop with CVSROOT=(.*)/$1/ } @result;
print DEBUG2: \$cvsroot=\n$cvsroot\n;
$cvsroot =~ s/^.*:(.*)$/$1/;# remove any pserver stuff
print DEBUG3: \$cvsroot=\n$cvsroot\n;
--
I tested the above and got the output below.(note I changed the actual IP
address shown)
Using a non existing file makes the program run quickly.
miller@cmp:/home/miller/cvs_stage/cm_tools: testit
DEBUG1: @result=
- main loop with CVSROOT=:pserver:miller@cmp:/sdhs_mnt2/cvsroot
- Connecting to cmp(123.123.123.123):2401
cvs server: nothing known about no_such_file
===
File: no file no_such_file Status: Unknown
Working revision: No entry for no_such_file
Repository revision:No revision control file
DEBUG2: $cvsroot=
:pserver:miller@cmp:/sdhs_mnt2/cvsroot
DEBUG3: $cvsroot=
/sdhs_mnt2/cvsroot
Dale Miller
-Original Message-
From: Reinstein, Shlomo [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 7:35 AM
To: '[EMAIL PROTECTED]'; Reinstein, Shlomo; [EMAIL PROTECTED]
Subject: RE: How to find out the CVSROOT and location in the
repository of a w orking directory
Hi,
In my question, I was referring ONLY to the CVSROOT (and repository
location) of a working directory. Inside a working directory, the
information is stored in the CVS/Root and CVS/Repository
files, and the
CVSROOT environment variable is not at all interesting (because it is
overriden by the CVS/Root file).
Like I said, I could read the CVS/Root file, but I consider
this file to be
CVS internals, and thus reading it is not a clean solution
(that is, I
would have to change my script if the implementation of CVS
changed and this
file was renamed, for example).
I got another answer that said to run cvs -t status (use
the global -t
option). The problem with this, as far as I'm concerned, is
that the CVSROOT
information from the -t option goes to the standard error,
rather than the
standard output.
Thanks,
Shlomo
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 3:27 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: How to find out the CVSROOT and location in the
repository
of a w orking directory
Shlomo,
You could have your perl program check the environment for
CVSROOT as shown
here:
my $CVSROOT = $ENV{'CVSROOT'};
if ($CVSROOT eq ) {
print CVSROOT is not defined - aborting\n;
exit 1;
}
If you are using pserver you could remove the pserver
information using:
$CVSROOT =~ s/^.*:(.*)$/$1/;# remove any pserver stuff
You could also check the CVS/Root file at the first directory
in a work
area. The content of it should match CVSROOT.
Dale Miller
-Original Message-
From: Reinstein, Shlomo [mailto:[EMAIL PROTECTED]]
Sent: Sunday, June 23, 2002 9:11 AM
To: '[EMAIL PROTECTED]'
Subject: How to find out the CVSROOT and location in the
repository of a w orking directory
Hi,
Is there a clean way to find out what is the CVSROOT of a working
directory and where in the repository it is located? I need
to find that out
from within a Perl script, and by clean I mean that I
prefer not to look
into the CVS/Root and CVS/Repository files, because I
consider them to be
CVS internals that might change some day.
I know that using cvs status I can find
How to find out the CVSROOT and location in the repository of a working directory
Hi, Is there a clean way to find out what is the CVSROOT of a working directory and where in the repository it is located? I need to find that out from within a Perl script, and by clean I mean that I prefer not to look into the CVS/Root and CVS/Repository files, because I consider them to be CVS internals that might change some day. I know that using cvs status I can find out the whole repository path, but there is no separation between the CVSROOT and the location inside the repository. To be more specific about what I need (maybe there's a way to do it without caring for the CVSROOT and location), I have a file in each module that has a fixed name and is used by my script to enable users to lock the module for a short time. Whenever a new branch is created for a module, this file should be initialized for that branch, to indicate that the branch is not locked. To do this, the script should modify it and commit a new revision of it into the branch. (This is needed because the file might indicate locked state for the root of the branch.) In order to do this, I want to check-out a fresh copy of that file (okay, with its whole directory) to a temporary directory, and then do these things on the copy in the temporary directory. In order to check it out, I need the CVSROOT and location within the repository. Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Changing the type of files from text to binary
Hi, I work with CVS 1.11. I would like to change the type of .dsp and .dsw files (Project files and Workspaces of MSDEV) in my repository to binary, so that they can be used with MSDEV even when checked-out on Linux. The problem with that is that changing the type to binary (using cvs admin -kb ...) will cause all existing revisions of the files to become unusable, since they will stay in canonical (Unix-) format in the repository, and they will not be converted to Windows format even when checked-out on Windows. Multiple revisions of these files are currently in use. Is there a safe way to change the format to binary and have the existing revisions stay usable? A long time ago I got a solution: Some script or program that will create a new file in binary format, check-out each revision of the old file, convert it to the appropriate format, and check it in to the new file, and finally get rid of the old file and rename the new one. The commit date and username will not be maintained, probably, but it's better to have working revisions than to keep this information. Does such a program/script exist? BTW, I have already sent this message to the list, however, I didn't know that I had to be subscribed to it, and I got the message that I need to wait until the list moderator can see the message and decide if I can send it. Since I don't know how long that will take, and I cannot wait much, I am sending this email again. Sorry if that's inconvenient. Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How cvs get works
And how does it send each file across the network in client/server? (e.g., does it use ftp or something like that?) Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 4:53 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How cvs get works Reinstein, Shlomo writes: I have a small question about the internals of cvs get: How does cvs get transfer the files from the repository to the checkout directory after extracting them from the RCS files? (How does it do that when the repository is mounted locally and how does it do it in a client/server mode?) When running locally, CVS reads the RCS file and writes the extracted file directly into the checkout directory. When running client/server, the server does a local checkout into a temporary directory and then sends each file across the network connection to the client who writes them into the checkout directory. -Larry Jones I don't want to be THIS good! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How cvs get works
Hi, I have a small question about the internals of cvs get: How does cvs get transfer the files from the repository to the checkout directory after extracting them from the RCS files? (How does it do that when the repository is mounted locally and how does it do it in a client/server mode?) Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Special case when merging a branch to the main trunk
Hi, A file that we removed on a branch has a new revision on the main trunk (after the branch was created). When we merge the branch into the main trunk, CVS keeps the file with the new revision, and does not report a conflict. In our specific case, the merge should remove the file, because the changes done along the branch make this file useless. Of course, CVS can't just remove that file when we merge, because it cannot know which of the changes we prefer, the one along the branch or the new revision on the main trunk. However, I would expect CVS to report a conflict in this case. When using the -t global option, I see that CVS recognizes this case. I think it's a bug that it doesn't report a conflict. What do you think? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
LockDir option in CVSROOT/config
Hi, We're using CVS on both Windows and Linux, using the :local: access method. Our repository is located on AFS, from Linux it's accessible as /afs/..., and from Windows the repository is accessible using some drive letter that is mapped to the root of AFS. I now want to use the LockDir option in CVSROOT/config to change the location where CVS creates its lock directories, but I have a problem: How do I specify a directory in a way that will be meaningful to CVS on both Windows and Linux? If I use /afs/..., CVS on Windows won't accept that, and if I use :local:z:\..., CVS on Linux won't accept that. I know that the natural solution is a CVS server - but it's not trivial for us to switch to client/server because of some administrative issues, and it will take time until we get there. For the mean time - how do I make LockDir work? I noticed that I cannot specify relative locations (e.g., ../Locks). Is there an option to specify the directory relative to the CVSROOT? Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question about LockDir
Is there a different solution? Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 11, 2001 11:56 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Question about LockDir Reinstein, Shlomo writes: But I have a problem with that: CVS versions 1.9 and older do not support the LockDir option (as written in the Cederqvist), and therefore if two different developers use different versions of CVS, e.g., one developer uses CVS 1.9, and the other uses CVS 1.11, then they can create write locks in two different locations, commit to the repository at the same time, and corrupt the repository. Use client/server CVS instead of a network-mounted repository. That way, you only need to worry about the server version. -Larry Jones Hmm... That might not be politic. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Per-directory sticky tags - a possible bug?
Hi, I'm using CVS version 1.10.7 on Windows (not using the client/server model). I have a CVS project that is made of some directory tree, where the topmost directory does not contain any files: root subdir1 subdir2 ... The root directory of the project (root) does not contain any files; all files are located in the sub-directories of root. When I use cvs update -r tag-name in the working directory of root, CVS updates the project to the version indicated by tag-name. In the CVS sub-directory of each working directory, it creates the Tag file which indicates the sticky tag. When tag-name is not a branch tag (i.e., it is not the name of a branch), the CVS/Tag files in the sub-directories of root contain the right thing: Ntag-name. However, the CVS/Tag file in the working directory of root, contains: Ttag-name, as if this is a branch tag. This means that I can (I tried, and it works) add files, modify them and commit them in the working directory of root, while I cannot do so for the sub-directories. Is this a bug in CVS? If not, can you explain to me the idea behind this? One more thing that is somehow related to the above: My group always treats a whole CVS project as a single entity - tags are always applied to whole projects and not to specific files/directories of a project. Given that, is there a way for me to know whether my working copy of a project is set to a branch or not? (not just to a branch tag, but to a tag that belongs to a branch) (Let's say I forgot if I checked-out from a branch or not) Thanks a lot, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Merging different types of files
Hi, I don't see how the cvswrappers file can help me, because for the *same* files I would like to see a different behavior, depending on the command. When I check-out/check-in source files, I would like the keyword substitutions to take place, e.g., I would like $Revision$ to be expanded to the version of the file. When I merge source files (in branches), I would like to avoid the keyword substitutions so that I don't get false conflicts about the keywords. Is there a solution for this? Is there a simple utility that eliminates the false conflicts generated by the keyword substitution? I read that I can determine a filter to work on each file based on its name when the file is checked-out or checked-in, however, the manual also says that these options are not available when you work in a client/server model. (We currently don't use client/server, but we'll do so soon.) Thanks, Shlomo -Original Message- From: John Minnihan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 04, 2001 8:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Merging different types of files Define the file handling in cvswrappers, such that the expansion mode is appropriately applied on a per file basis rather than wholesale via a command line switch. This technique is discussed in many places (probably this list archive for starters). [EMAIL PROTECTED] wrote: and in general we're interested in the keyword substitution feature for the text files. However, the binary files are stored in the repository with the -kb option, to prevent the keyword substitution and the line-ending conversions from taking place. What is the right way to merge such a project? - John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Merging different types of files
Hi, My CVS project contains two types of files: Text files (source code), and binary files. The text files contain CVS keywords in them (e.g. $Header$), and in general we're interested in the keyword substitution feature for the text files. However, the binary files are stored in the repository with the -kb option, to prevent the keyword substitution and the line-ending conversions from taking place. I created a branch (let's call this branch br) in my project, and now I would like to merge the changes made on the branch back to the main trunk. If I do it using: cvs update -j br then I guess false conflicts in all the text files about the CVS keywords (e.g., because the revision numbers on the branch are different from the revision numbers on the main trunk), and I need to work to remove those conflicts. On the other hand, if I do it using: cvs update -j br -kk then I don't get the false conflicts about the CVS keywords, but I get damaged binary files. What is the right way to merge such a project? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stale CVS locks
Hi, We work on CVS on both Windows NT/2000 and Linux. Most of the time we work on Windows, and Windows users are used to Ctrl+Break... Anyway, yesterday Larry Jones told me I should still send a bug report about this, so I did that. About SIGQUIT, I don't know, I am not familiar with the Unix signals. Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 9:44 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] Subject: RE: Stale CVS locks [ On Wednesday, June 13, 2001 at 08:25:02 (+0300), Reinstein, Shlomo wrote: ] Subject: RE: Stale CVS locks Thanks for the info. I would just like to make a small clarification: If the user clicks Ctrl+C, CVS traps the signal and cleans up the locks. However, it doesn't do so when the user clicks Ctrl+Break. With this clarification, should I still report it as a bug? I'm assuming your platform is M$? If so then is CtrlBreak the same as a tty generated SIGQUIT in Unix (usually a CTRLBackSlash? If so then it's not a bug, but rather a feature. Users should not get into the habit of using SIGQUIT unless they are actually attempting to purposefully crash the program and debug the resulting core dump. It would be possible, but generally speaking incorrect, for CVS to trap SIGQUIT. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stale CVS locks
Thanks for the info. I would just like to make a small clarification: If the user clicks Ctrl+C, CVS traps the signal and cleans up the locks. However, it doesn't do so when the user clicks Ctrl+Break. With this clarification, should I still report it as a bug? As for your question why I cannot use the client/server model - that's because we implemented many wrapper scripts around CVS that provide some additional functionality that we need, and those scripts do not support the client/server model. We are considering to switch to this model, but it will take time, and until then, we get a lot of trouble with these stale CVS locks. Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 12, 2001 9:03 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Stale CVS locks Reinstein, Shlomo writes: It happens many times that CVS users execute some CVS command (e.g., cvs log), and then, before it finished executing, they abort the command using Ctrl+Break or a similar manner. The outcome of this is that the read locks generated by CVS remain in place, and prevent other users later from checking-out modules (or performing other CVS operations on these modules that contain the read locks). That shouldn't happen -- CVS (at least the Unix version) traps the break signal and cleans up the locks before exiting. If this really happens, it's a bug in your CVS. Please report it as such, but be sure to identify the specific version and release of CVS that it applies to. I'd like to know, is there a common way of handling these problems? If not, can you recommend us how to deal with this? If don't know if it matters for this problem, but we're using CVS (the same repository) from both Windows and Linux, and we're not using the client/server model of CVS (and we can't start using this model now). The Ctrl+Break case may perhaps be solved by capturing those keystrokes, but there may be other reasons for stale CVS locks such as when a machine crashes, so I think this problem should be solved more generally. The problem occurs so rarely in practice (at least on Unix-like systems) that removing the stale locks manually has been a perfectly reasonable way to address the problem. It sounds like you're using a network- mounted repository (Samba?), which is practically begging for trouble, so you shouldn't be surprised that you're finding it. You really should switch to client/server CVS -- why do you say you can't? -Larry Jones Hello, local Navy recruitment office? Yes, this is an emergency... -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Stale CVS locks
Hi, It happens many times that CVS users execute some CVS command (e.g., cvs log), and then, before it finished executing, they abort the command using Ctrl+Break or a similar manner. The outcome of this is that the read locks generated by CVS remain in place, and prevent other users later from checking-out modules (or performing other CVS operations on these modules that contain the read locks). I'd like to know, is there a common way of handling these problems? If not, can you recommend us how to deal with this? If don't know if it matters for this problem, but we're using CVS (the same repository) from both Windows and Linux, and we're not using the client/server model of CVS (and we can't start using this model now). The Ctrl+Break case may perhaps be solved by capturing those keystrokes, but there may be other reasons for stale CVS locks such as when a machine crashes, so I think this problem should be solved more generally. Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Skipping directories in checkout
Hi, While running cvs -d path-to-CVSROOT get some-project, I get the following message: cvs checkout: Updating some-project cvs checkout: cannot open directory path-to-CVSROOT/some-project: No such file or directory cvs checkout: skipping directory some-project The reason CVS is unable to open the repository directories of this project is that there is a network problem and the connection to the file server (not CVS server!) in which the repository is located is unstable. The question is, why does it skip the directory? Why does it not die with a fatal error message? I run many such cvs get commands from a script, and the fact that it skips the directories and returns with a good exit status prevents the script from recognizing that it didn't manage to checkout the project. Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Skipping directories in checkout
Hi, I fully agree with the philosophy - I'd rather have more than less. But at the end of the checkout operation, I expect to know from CVS (through its exit status, and perhaps also through an error message) that something went wrong. Otherwise the only way for me to intercept it is to capture the errors from the standard error (or output). Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 31, 2001 10:18 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Skipping directories in checkout Reinstein, Shlomo writes: The reason CVS is unable to open the repository directories of this project is that there is a network problem and the connection to the file server (not CVS server!) in which the repository is located is unstable. The question is, why does it skip the directory? Why does it not die with a fatal error message? Because the philosophy is that you'd rather have more of what you're trying to checkout than less. Why do you have (part of) your repository on an unreliable network filesystem -- is it read-only, junk you don't really care about, or do you just enjoy living dangerously? -Larry Jones See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Strange Permission denied problem during merge
Hi, I got a strange behavior of CVS (version 1.10.7, running on WinNT) when trying to merge(update) a file. The situation is as follows: I checked-out a project from the repository. One of the files in the project (let's call it x.cpp) was checked-out with version 1.5. I modified the file locally, and while I did that other people committed new versions of this file into the repository, and the current latest version of this file in the repository is 1.7. I typed cvs update in the working directory of this file, and expected it to merge the differences between 1.5 and 1.7 into my version of the file. However, I got the following output from this cvs update command: cvs update: could not open output file: Permission denied cvs update: subsidiary diff failed I checked that the necessary environment variables (e.g., HOMEDRIVE, HOMEPATH, TEMP, TMP) are defined correctly. I also tried a few CVS options (such as cvs -l update to avoid logging, or even cvs -n update so it doesn't modify the file in the working directory!), but it kept displaying the same error, even with -n. I tried to move my changed file aside and type cvs update, and this works fine. But for some reason, merging into my (changed) version of the file always displays this error. If it helps, I also ran cvs -t update to see a trace, and the output is below (I just changed the directory names and the filenames because I'm not sure I'm allowed to send this information, it might be considered confidential). Do you have any idea what the problem can be? I found out that moving the whole working directory to another drive solved the problem - in the other drive, cvs update merged the file correctly and did not display this error. The file is not read-only or anything like it. Thanks a lot, Shlomo === Output of cvs -t update: cvs update: notice: main loop with CVSROOT=:local:z:\some_path cvs update: Updating . - checkout (z:\some_path/some_project/x.cpp,v, 1.5, , (function)) - unlink(.#x.cpp.1.5) - copy(x.cpp,.#x.cpp.1.5) - chmod(x.cpp,100666) RCS file: z:\some_path/some_project/x.cpp,v retrieving revision 1.5 - checkout (z:\some_path/some_project/x.cpp,v, 1.5, , E:\user_tmp\71 ) retrieving revision 1.7 - checkout (z:\some_path/some_project/x.cpp,v, 1.7, , E:\user_tmp\72 ) Merging differences between 1.5 and 1.7 into x.cpp cvs update: could not open output file: Permission denied cvs update: subsidiary diff failed ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
A problem with CVS commands that modify the repository
Hi, We've been working on our CVS repository for a while, and everything used to be ok. Starting today, we are getting messages like the following: cvs [commit aborted]: could not open lock file `some-path-in-the-repository/some-file,' : File exists We got similar messages when trying to tag the repository. Looking into the repository I found out two files for some-file: * "some-file,v" - this is the usual (RCS) file in the repository, and * ",some-file," - this is the new version of the (RCS) file in the repository, which should replace "some-file,v". Looking at the permissions in that repository directory, I noticed that all ",v" files were read-only. Changing them to writable (using 'chmod +w *,v') solved the problem. My questions: 1. Should the files in the repository be writable? 2. How can it be that we used to commit and tag without a problem, and suddenly we are unable to do so (in the same repository directories)? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Strange conflicts as a result of merging a branch into the main trunk
Hi, I have encountered merge conflicts that are very strange to me: At some point during the development of a project, we created a branch from the main trunk. A lot of work was done in that branch, but ever since the branch was created, NO work was done on main trunk. That is, the latest version of the main trunk is the same version from which the branch was forked off. At some point, we wanted to merge the work done on the branch back into the main trunk. To do this, we checked-out the latest version of the project from the main trunk, and in the working directory that we got, we used: cvs update -j branch-name Since no work was done on the main trunk since the creation of the branch, I'd expect CVS to just update the working directory with the newest version of the branch. (which would be the result of merging all changes made in the branch into the working directory.) However, the results were different. During this merge, we encountered conflicts! Can you explain this? I'll give a few more details on this. We have a file named "isis.c". It's latest version on the main trunk is 1.81. The latest version of this file on the branch is 1.81.2.17. When we merged the changes made on the branch into the main trunk, CVS output showed that it merged the changes between 1.81 and 1.81.2.17 into the working directory. The working directory contained 1.81 itself (the latest version of the main trunk), so I'd expect to get 1.81.2.17 as a result of the merge. However, instead of that I got conflicts... Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Problems with CVS version 1.10.8 on Windows 2000
I'm sorry, you must have skipped my reply to Larry. I tried (even before I posted the first message about this problem! ) to use forward slashes (the very same command-line that you wrote here), but it doesn't work either. I get the following: cvs [checkout aborted]: CVSROOT z:/iil/iswp/data/apt/ISIS/repository must be an absolute pathname So whether I use forward slashes or backward slashes, it doesn't work - I get the above message. And again, version 1.10.7 of CVS works fine with back-slashes, but 1.10.8 doesn't work with any (forward or backward) slashes. Can this message be the result of some problem in environment variables? Can it be that there's some environment variable that CVS uses and is not defined properly, and CVS just gives me the above message for something which is not related to the CVSROOT path? Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 01, 2001 4:27 PM To: Reinstein, Shlomo Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] Subject: Re: Problems with CVS version 1.10.8 on Windows 2000 Please reread Larry's original response and follow his advice (always use forward slashes in pathnames given to CVS). This: cvs -d :local:z:/iil/iswp/data/apt/ISIS/repository co trycvs should work just fine. The : after z will not be confused by CVS as a field separator. P.S. - even in MS' own software, "\\z\" is *NOT* equivalent to "z:\". The former describes a *machine*, and the latter describes a *disk* mounted (either locally or remotely) on the local machine. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problems with CVS version 1.10.8 on Windows 2000
Hi, Using CVS version 1.10.8 on Windows 2000, I am trying to check-out a module using the global "-d" option, specifying the full path of the repository: cvs -d :local:z:\iil\iswp\data\apt\ISIS\repository get trycvs (where 'z:\iil\iswp\data\apt\ISIS\repository' is the full path of the repository, under which the CVSROOT directory resides, together with the "trycvs" module. Drive z: in my case is mapped to the root of an AFS tree.) What I get in return is: cvs [checkout aborted]: CVSROOT z:\iil\iswp\data\apt\ISIS\repository must be an absolute pathname What can the problem be? Isn't z:\iil\... an absolute pathname? Note that the same command-line worked fine with version 1.10.7 of CVS (also on Windows 2000). Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Problems with CVS version 1.10.8 on Windows 2000
Hi, I forgot to say that in my previous email - I also tried it with forward slashes (after reading in the mailing-list about similar problems): cvs -d :local:z:/iil/iswp/data/apt/ISIS/repository get trycvs Doesn't work either - I get the very same error message from CVS. Please note that, like I said in the previous email, the same command-line (even with backward-slashes) works with version 1.10.7 of CVS. Shlomo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 6:12 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Problems with CVS version 1.10.8 on Windows 2000 Reinstein, Shlomo writes: What can the problem be? Isn't z:\iil\... an absolute pathname? No, it's not. There are some parts of CVS that insist on forward slashes (/) instead of backward slashes (\) and this is one of them. I understand that this is inconvenient for Windows users, but I urge you to get used to using forward slashes with CVS or you'll have no end of strange problems. -Larry Jones That's one of the remarkable things about life. It's never so bad that it can't get worse. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Question about the command-line for committing
Hi, The "commit" command of CVS has an option, "-m", for specifying a log message on the command-line instead of interactively using an editor. But what happens when the commit is recursive and there are files in other directories that will be committed? Is there a way to specify (on the command-line) different log messages for different directories? While this question seems to be irrelevant (why would a user want to specify different log messages to different directories through the command-line?), I am interested in this for testing purposes -- I have set up some scripts to handle commit commands using the "loginfo" and "commitinfo" files in the repository, and I would like to have an automatic script to test them. One of my test cases is providing a different log message for each directory, and if I can't do that from the command-line then this test case has to be manual (at least partially - I will need to wait for the editor and enter the log message). Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Question about the command-line for committing
Hi, Thanks, but (I think) this is not what I need. You see, I need *the same* "commit" command to commit files from several directories, and give a different log message for each directory. The scripts that I run using the "loginfo" and "commitinfo" files collect information about the commit as it goes from directory to directory (and store the information in temporary files), and when the last directory has been committed, it processes the collected information, then deletes the temporary files. For this reason, I would like the same commit command to be able to commit several directories with different log messages. Thanks, Shlomo -Original Message- From: Rob [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 11, 2001 11:25 AM To: Reinstein, Shlomo Cc: '[EMAIL PROTECTED]' Subject: Re: Question about the command-line for committing Hello, You can specify a path/filename as well. i.e. cvs commit -m "this dir is cool" cooldir/ cvs commit -m "this file is not cool" notcool/notcool.c On Thu, Jan 11, 2001 at 01:06:04AM -0800, Reinstein, Shlomo wrote: Hi, The "commit" command of CVS has an option, "-m", for specifying a log message on the command-line instead of interactively using an editor. But what happens when the commit is recursive and there are files in other directories that will be committed? Is there a way to specify (on the command-line) different log messages for different directories? While this question seems to be irrelevant (why would a user want to specify different log messages to different directories through the command-line?), I am interested in this for testing purposes -- I have set up some scripts to handle commit commands using the "loginfo" and "commitinfo" files in the repository, and I would like to have an automatic script to test them. One of my test cases is providing a different log message for each directory, and if I can't do that from the command-line then this test case has to be manual (at least partially - I will need to wait for the editor and enter the log message). Thanks, Shlomo ___ 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
The recursive behavior of CVS
Hi, Can anyone explain to me the recursive behavior of CVS? To be more precise, can anyone explain to me how CVS determines whether it should go into a subdirectory and continue to run there or not? Here were have arbitrary directory structures of sources checked-out from CVS. The sources in any single directory tree can belong to various CVS projects, even from various CVS repositories. In other words, CVS projects are mixed in each tree, in a way that is the most convenient for us to work with them. For example, we can have a tree as follows: /root/project1 /root/project2 /root/project2/project3 where each of 'project1', 'project2', 'project3' may be checked-out from a different repository. I found out that when running CVS commands like "diff", "log" (as well as most other recursive commands) from the "/root" directory, sometimes the command also runs in 'project3' and sometimes it doesn't. I couldn't figure out how CVS decides whether it should go into a sub-directory or not. Basically, since we normally check-out projects in such trees, I would like to write some tool that will extend the recursive behavior of CVS by checking which working directories in the tree CVS is going to ignore and then running CVS separately also on these directories. Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Email notification of checkout...
I have never used it, but according to the CVS manual by Per Cederqvist
(page 127, C.1.5. Module options), you can add an option ('-o prog') in the
'modules' file in the repository which will specify a program to run
whenever files in a module are checked out. The program runs with a single
argument, the module name. So, try to specify a program there which will
send the email notification.
Shlomo
-Original Message-
From: Stuart Carter [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 09, 2000 1:31 PM
To: [EMAIL PROTECTED]
Subject: Email notification of checkout...
Apologies if this is a silly question, but I've just taken over
the CVS repository, and now my boss wants email notification of
check-outs (by lunch-time!)...
Is there any easy way to do this? I have looked into the history
command which displays them, but doesn't email. I've also looked
into the email notification system (watch) and it doesn't seem
to notify of checkouts, just edit/unedit and commit.
Am I missing something?
Thanks in anticipation,
Stu
Question about the CVS mailing lists
Hi Greg, Sorry for asking this - but what is the "CVS-II Discussion Mailing List"? I am subscribed to [EMAIL PROTECTED], and I have a rule in my email client to move all the messages from that mailing list to some folder, but I keep getting the CVS-II discussion mailing list messages in my inbox, while the other messages go to the folder as expected. I know that there was a split of the CVS mailing list, but I thought that the result was only the cvsgui mailing list. Thanks, Shlomo
RE: CVS pids and the pids of its kids
Ok, one thing that I did not say is that we don't use "cvs commit" directly
here, we have a wrapper which we run instead of "cvs commit" :-) and this
wrapper runs "cvs commit" after setting its pid in some environment
variable.
I didn't say how to do it if you don't have a wrapper, I just thought that
it should not be a problem since:
1. Donald Shart wrote this thought, so I thought he knew how to do it, and
2. There is some common parent to both anyway (for example, the shell that
ran this command), so, just by knowing how many levels up you need to go
from each process, you can find the pid of the common parent. In my case it
was just simpler because we need to wrapper to do other things anyway.
And mostly, I wrote this response for the 2nd paragraph (the "duh" part)...
Shlomo
-Original Message-
From: Laird Nelson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 03, 2000 4:41 PM
To: Reinstein, Shlomo
Cc: 'Donald Sharp'; [EMAIL PROTECTED]
Subject: Re: CVS pids and the pids of its kids
"Reinstein, Shlomo" wrote:
Hi,
I've used that method to communicate information between the commitinfo
and
the loginfo of the same commit process - that is, using the pid of the
"cvs
commit" process itself, which is the parent of both.
How have you done this? The pid of the "cvs commit" process itself is
NOT the parent of both commitinfo and loginfo. The fork-and-exec
happens (apparently?) *after* the commit actually occurs. This means
that commitinfo and verifymsg are run by the same pid, but loginfo is
not. As the Cederqvist manual says somewhere, the order of the relevant
*info scripts is this:
1. commitinfo
2. verifymsg
(commit happens if (1) and (2) let it happen)
3. loginfo
(1) and (2) are run by the same parent pid; (3) is not.
Just one point: In case
you don't work with a CVS server, and people can access the repository
from
various machines, the pid is not enough for distinguishing between
commits,
you need to use both the pid of the commit process and the name of the
machine.
Yes, of course. {whap} Duh.
Cheers,
Laird
RE: CVS pids and the pids of its kids
Hi, I've used that method to communicate information between the commitinfo and the loginfo of the same commit process - that is, using the pid of the "cvs commit" process itself, which is the parent of both. Just one point: In case you don't work with a CVS server, and people can access the repository from various machines, the pid is not enough for distinguishing between commits, you need to use both the pid of the commit process and the name of the machine. Shlomo -Original Message- From: Donald Sharp [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 03, 2000 7:18 AM To: Laird Nelson Cc: Donald Sharp; [EMAIL PROTECTED] Subject: Re: CVS pids and the pids of its kids Hmmm as a thought... Have a control file that tracks directory names based on the original cvs invocation pid.The commitinfo script would write to this file the location of it's temp directory. The Loginfo script would read the file and then go get the directory( dropping/whatever ). I would also base the control file's name on the original cvs invocations pid, so that you wouldn't have to worry about parsing the control file too much... thoughts? donald On Wed, Aug 02, 2000 at 07:18:16PM -0400, Laird Nelson wrote: Donald Sharp wrote: What does it matter? 1. If my commitinfo script leaves a dropping behind it in the cvs temp directory (which is of the form /tmp/cvs-serv20873 when cvs is invoked via rsh or pserver or probably gserver), and my loginfo script wants to retrieve that dropping, the loginfo script needs to know the name of the temp directory. 2. To get the name of the temp directory, the loginfo script needs to know the pid of the cvs process that ran commitinfo, because that's embedded in the temp directory name, as detailed above. 3. But the pid changes between commitinfo time and loginfo time. So I'm trying to see if it changes deterministically. more than likely cvs is just forking and execing... Doesn't a fork and exec result in...two addi...aha, but the second cvs (the one that's exec'ed) is then invoking my loginfo script so that's why loginfo getppid() returns commitinfo.getppid() + 3. Got it. Cheers, Laird
Sorting tags
Hi, Is there a way of sorting tags according to the revisions that they tag? Specifically I would like to find the latest tag that was put on a given branch. (Suppose that all files in a CVS project are always tagged together, so in general I could take the output of "cvs log" for any single file to see all tags.) I don't mind writing a script to parse the output of "cvs log" in order to extract the latest tag, but I still have a problem: What is one tags the project, then removes a file (cvs remove, then cvs commit), and then tags again? Will I be able to find out which of the two tags is newer? (And by "newer", I don't mean the tag that was last put in the repository, because one can tag older versions too.) Thanks, Shlomo
Branches in CVS
Hi, I have read the recent messages regarding branch locking in CVS. I tried to do a similar thing myself, and I get strange output from CVS, which I cannot understand even after reading these messages. Here are the commands that I gave and the output of CVS for these commands: (I typed these commands from inside a working directory of some CVS project that I created to test branch locking. This project contains a single file, "hello.c".) cvs tag Root_of_Second-Branch cvs tag: Tagging . T hello.c cvs tag -b Second-Branch cvs tag: Tagging . T hello.c cvs admin -lSecond-Branch cvs admin: Administrating . RCS file: [path-to-project]/hello.c,v cvs admin: [path-to-project]/hello.c,v: branch Second-Branch absent cvs admin: cannot modify RCS file for `hello.c' (I replaced the long path to the project repository by with [path-to-project].) What is the problem here? I clearly created a branch in the second command that I gave, and CVS shows that "hello.c" was tagged with the branch tag. If I now do "cvs log", I see the symbolic name Second-Branch for "hello.c". I can also update to the branch tag. Here's CVS output for these commands: cvs log hello.c RCS file: [path-to-project]/hello.c,v Working file: hello.c head: 1.2 branch: locks: strict access list: symbolic names: Second-Branch: 1.2.0.2 Root_of_Second-Branch: 1.2 First-Branch: 1.1.1.1.0.2 Root_of_First-Branch: 1.1.1.1 start: 1.1.1.1 yoyo: 1.1.1 keyword substitution: kv total revisions: 5; selected revisions: 5 description: .. cvs update -rSecond-Branch cvs update: Updating . cvs status hello.c === File: hello.c Status: Up-to-date Working revision:1.2 Wed Jul 19 11:37:44 2000 Repository revision: 1.2 [path-to-project]/hello.c,v Sticky Tag: Second-Branch (branch: 1.2.2) Sticky Date: (none) Sticky Options: (none) Is it a problem that "cvs status" shows me a version number of 1.2.2 for the branch, while "cvs log" shows me version 1.2.0.2 for the branch of "hello.c"? Thanks, Shlomo
RE: Watching history without a working directory
Hi,
Thank you very much for your answer, however, the result of this "rdiff"
line is a list of files with their (numeric) revisions, while I'm interested
in the latest tag (which is common to all files), not in the revisions of
all files.
For example, say I do the following:
cvs get module1
cd module1
[edit some files of module1]
cvs commit
cvs tag ThisIsMyCommitTag
cd ..
cvs release module1
Now I would like to get the latest tag ("ThisIsMyCommitTag") of module1,
without checking it out again. I want only the tag, I don't want to store
the revision of each file of module1. I have a product which is composed of
many such modules, each module is tagged after each commit, and I would like
to have a list of modules and their latest tags in some file that belongs to
the product (and this determines the version of the product - each change in
this list will make a different version of the product).
Another reply that I received said that this (i.e., getting latest tags
without checking-out first) cannot be done with the current version of CVS.
Thanks a lot again,
Shlomo
-Original Message-
From: Pavel Roskin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 06, 2000 8:21 PM
To: Reinstein, Shlomo
Cc: '[EMAIL PROTECTED]'
Subject: Re: Watching history without a working directory
Hello, Shlomo!
Is it possible to watch the history of a CVS project (like "cvs log")
without having a working directory of the project? I couldn't figure it
out
"cvs log" and "cvs history" is not the same. "cvs history" works without
the working directory, as it is repository-wide.
"cvs log" works on separate files. You need to have a "home" in the CVS
sense to address specific files.
To be more precise, I need to write a script which extracts (i.e., finds)
the latest tags of a large list of CVS projects. I do not want to
check-out
all these projects just for the purpose of extracting the tags, since this
would take a very long time, and is logically not needed. So, how can I do
that?
This is a feature that should eventually be added "cvs export".
For now, use "cvs rdiff" against revision 0.
cvs -d your_cvs_root rdiff -r0 -s .
Regards,
Pavel Roskin
Watching history without a working directory
Hi, Is it possible to watch the history of a CVS project (like "cvs log") without having a working directory of the project? I couldn't figure it out from the Cederqvist manual; it seems to me that logically there should be no need for a working copy of a project in order to just view the history and the tags - the history is in the files which are stored in the repository, so why should we need to check-out a project to see its history? When I run "cvs log", and the current directory does not have a CVS subdirectory in it, it tells me: cvs [log aborted]: there is no version here; run 'cvs checkout' first To be more precise, I need to write a script which extracts (i.e., finds) the latest tags of a large list of CVS projects. I do not want to check-out all these projects just for the purpose of extracting the tags, since this would take a very long time, and is logically not needed. So, how can I do that? And one more question - this mailing list has thousands of questions and answers, and I cannot go over all of them to see there are already answers to my CVS questions there. Is there a "good" way of searching this mailing list? In egroups, there's a "search" button, but it seems to be very limited, a very simple search. Thanks, Shlomo
