Re: cvs tag performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hridyesh Pant [EMAIL PROTECTED] writes: Hi All, My cvs tag command is suddenly taking too much time while tagging a code of 2GB .It is affecting our performance. My system configuration after top command is as below 11:47am up 66 days, 19:24, 4 users, load average: 15.23, 13.82, 13.14 155 processes: 150 sleeping, 5 running, 0 zombie, 0 stopped CPU0 states: 41.0% user, 3.1% system, 0.0% nice, 54.1% idle CPU1 states: 100.0% user, 0.0% system, 0.0% nice, 0.0% idle CPU2 states: 28.0% user, 3.1% system, 0.0% nice, 68.0% idle CPU3 states: 75.0% user, 9.0% system, 0.0% nice, 15.1% idle Mem: 3946640K av, 3836128K used, 110512K free, 0K shrd, 73884K buff Swap: 6193120K av, 37112K used, 6156008K free 2637244K cached could any body help me what need to be done... Regards Hridyesh Not really. You need to see what kind of filesystem contention you are hitting. Remember that a tag operation will rewrite everyone of the ,v files in the list of files being tagged. Slow disk writes would impact it. However, the load of processes waiting to run (150 sleeping) would seem to indicate something else is the bottle neck unless every one of them are waiting for read or write locks in the repository. You may wish to look into using a memory filesystem on the box along with a LockDir directive in your CVSROOT/config file to point to it. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFC1nwq3x41pRYZE/gRAkn1AJ9f1EY3cgxQ9+m7YoloIgV+2DjpBgCfQj7J QelhfdWvGzogI60521YHJW4= =xpoR -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Exact branching date?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sensei [EMAIL PROTECTED] writes: Hi. I'm new to branching, I always used it just as tagging versions, never joining back with head... so pleas excuse me being naive :) I'd like to know if it's possible to know the exact date when a branching has been applied, without sticky dates, since I have none in my repository. You should be able to bracket the timeframe, but you will not be able to get it exactly. For the upper bound, the closest you can probably come would be the second immediately before the first commit to the branch. You would want to use one of the tools that plays with the 'cvs status' or 'cvs log' output to find the first commit to the branch (cvs2cl is a good choice). For the lower bound, you would want to take one second after the most recent commit to the parent branch prior to the upper bound time found in previous step. I'd like to diff some versions with the head, but using diff files from the original branching date to the lates branched version, and then but it back on head... but I need the branching date! :) For all practical purposes you should be able to use the upper bound timestamp. Something like this may be what you want cvs2cl.pl --no-ancestors --follow branch-name --tags --branches \ --revisions --chrono grep -B2 branch-name ChangeLog If I have misremembered the syntax, I am certain that some one else on the list will be able to help you. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFC1oI13x41pRYZE/gRApo6AJ9zqXNHVqB3B4bwrIc/LYfpCYhR5gCg5qIf ib/e0gF8/2ONr/ZU9xEl1io= =oIL3 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CCASE data import into CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Buozis, Martynas [EMAIL PROTECTED] writes: Is it possible to import data from CCASE into CVS ? If yes - how ? Thanks. You should use a search engine to find prior art... something like this describes how you might go about writing one for yourself... http://lists.gnu.org/archive/html/info-cvs/2001-06/msg00134.html You should also consider looking for something that can export from ClearCase into RCS as it is a short step from there to using CVS. If you come up with a script, feel free to post it to bug-cvs@gnu.org for possible inclusion into the contrib directory. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFC09RL3x41pRYZE/gRAvQTAJ47rUWCpBSQgvZYbr7AYCTSSWyhEACdEnlg UYTLDEpkhu9yM4Uue57ZvXs= =lAGA -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Locking CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S I [EMAIL PROTECTED] writes: Thank you. I'm not sure what /bin/test represents? To be replaced with the path to my proj? It represents the /bin/test (see 'man test' on your GNU/Linux box for more details) command to compare the output of the `id -u` command with the numeric value of your own id. Otherwise you would never be able to undo the change to the CVSROOT/commitinfo script and it would be locked forever. The ALL means that all possible modules will run this test during the commit phase. The : command will accept any argument and always return true. This will stop any warnings that cvs 1.12.x might want to give you for using the older style format string defaults. As always, it is recommened that you run tests on a repository other than your main repository to be sure you understand how things work. -- Mark mdb wrote: For cvs 1.11.x ALL /bin/test `id -u` = 12345 For cvs 1.12.x you might want to use ALL /bin/test `id -u` = 12345 : %r/%p %s This should return a non-zero error code for anyone other than the user with the uid 12345 which we would presume you would use your own userid and that you would be accessing the repository outside of the :pserver: method or have arranged for your :pserver: usage to use your real userid rather than masking it with the system userid. Other methods exist for just locking a single branch (such as the main trunk) using something like the contrib/cvs_acls file that comes with recent cvs distributions. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFC0qIA3x41pRYZE/gRAssoAJ94aJt2/mY6gWHZ+jIrmFOUqHpOuACeITqT mY14iW+q1tps5zWsRGV10uU= =l6yd -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs error: received broken pipe signal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yu He [EMAIL PROTECTED] writes: Hi all: After commit,always receive the following error message, cvs [server aborted]: received broken pipe signal What's the reason? Thanks a lot in advance! You have provided insufficient information as to your configuration. At a guess, you might not be reading all of the stdin being provided to your cvs trigger scripts. For better guesses, information like: - host OS information for server - host OS information for client - server version of cvs - client version of cvs - nature of commitinfo, verifymsg, loginfo scripts being used (if any) is desirable. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCzM+U3x41pRYZE/gRAuJCAKCqSqL/4wjCV3QoR45oAIuDgMyVsgCfQ/Wi jXrtVnZZQE1vvlDu/87VN54= =tfWn -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs error: received broken pipe signal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yu He [EMAIL PROTECTED] writes: Thanks a lot for your reminding. - host OS information for server: Redhat 9 - host OS information for client: Window 2000 - server version of cvs: cvs 1.11.6 - client version of cvs: wincvs 1.3 - nature of commitinfo, verifymsg, loginfo scripts being used (if any): in the attachment How is the attachment used? I am guessing it is only used from CVSROOT/commitinfo right? Is there anything in CVSROOT/loginfo ? additional information: the error comes up after the commit is succeeded and version number is changed. and error does not always comes up every time. but sometimes alternately or every three time. Ahh, this does not agree with your first problem statement where you said it always happened... Are you able to find anything in common with the times when it fails? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCzNdK3x41pRYZE/gRAltnAJ9iOe0I8ZJT9bC6pGq+0TNhwFhkXQCfTXyu VFeqwMKzQNKl4zP13Bau2B8= =VNoE -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs error: received broken pipe signal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 These two lines need to dispose of stdin: Original: project1 (chgrp -Rf project1 /usr/local/cvsroot/project1) project2 (chgrp -Rf project2 /usr/local/cvsroot/project2) Revised: project1 (chgrp -Rf project1 /usr/local/cvsroot/project1; cat) /dev/null project2 (chgrp -Rf project2 /usr/local/cvsroot/project2; cat) /dev/null Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCzN/e3x41pRYZE/gRAmr0AJ9s5/DMr7yEYugqRlp61oxQN8+5KACg0T9J 0064dezA7A87GjCC6NX3BV0= =gcll -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: error while installing CVS 1.11.20
ravish agarwal [EMAIL PROTECTED] writes:
I am getting following error while installing CVS-1.11.20.
On what operating system are you running?
What compiler version are you using?
# make
No suffix list.
make all-recursive
No suffix list.
Making all in lib
source='getpass.c' object='getpass.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I.. -I../src -g -c getpass.c
(Bundled) cc: warning 480: The -g option is available only with the C/ANSI C
pro
duct; ignored.
(Bundled) cc: getpass.c, line 40: error 1705: Function prototypes are an
ANSI
feature.
*** Error exit code 1
Stop.
*** Error exit code 1
Stop.
*** Error exit code 1
Please help me out. What is the possible cause of this error
regards
Note: You should consider getting a compiler that is able to deal with
ANSI C. Future releases of CVS (1.12.x) will give you many problems
otherwise as that release of CVS assumes a C89 capable standalone
compiler.
Does the following patch fix your problem?
-- Mark
ChangeLog entry:
2005-07-06 Mark D. Baushke [EMAIL PROTECTED]
* getpass.c (getpass): Add a KR style function definition.
Index: getpass.c
===
RCS file: /cvs/ccvs/lib/getpass.c,v
retrieving revision 1.1.2.4
diff -u -p -u -p -r1.1.2.4 getpass.c
--- getpass.c 2 Oct 2003 18:40:13 - 1.1.2.4
+++ getpass.c 6 Jul 2005 15:31:55 -
@@ -37,7 +37,12 @@
#endif
char *
+#if __STDC__
getpass (const char *prompt)
+#else
+getpass (prompt)
+const char *prompt;
+#endif
{
FILE *in, *out;
struct termios s, t;
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Opificius [EMAIL PROTECTED] writes:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
Maybe there is a Linux feature - something akin to setuid - that
operates on the top level repository directory?
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCxwa73x41pRYZE/gRAhQ3AJ9W5T0ZFGxZhOLYa3WqSNIZAgOCmACgzSMz
adob8OzUA267AGIbaEy8mK4=
=q9hb
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Opificius [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
The only problem now is that if a cvsadmin user introduces a directory
into the cvs repository using add, the directory is owned by him, not
by the global cvs user, and nobody else can check into/out of that
directory.
How do I automatically force new directories created by the cvs server
to be owned by the global cvs user, rather than the effective user?
This is the wrong question.
why is that? Maybe I should be talking group here not owner?
Why are new files and directories being created with the wrong group
on the server? Read: https://ccvs.cvshome.org/fom//cache/33.html
See also the paragraph of section '2.2.2 File permissions' of the manual:
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13
You could have the directories all be in a 'cvs' group and use
find $CVSROOT -type d -exec chgrp cvs g+s {} \;
Sorry about the typo.
: all the groups should be owned by group cvs
find $CVSROOT -type d -exec chgrp cvs {} \;
: all the group members should be able to write to it
find $CVSROOT -type d -exec chmod g+rwxs {} \;
find $CVSROOT -type d -exec chmod g+s {} \;
The cvs user could belong to this group 'cvs' as well as your admin
users. New files and directories created will inherit the groupid of the
parent directory. A crontab job could go thru and change the ownership
of the files and directories in the tree to that of the 'cvs' user on a
periodic basis as additional cleanup if desired.
g+s is not a valid arg for chgrp. what did you really mean here?
Oops, that was a typo... sorry about that.
my admin users do already belong to the cvs group, as do all the
repository directories.
I think what you're effectively saying here is that by setting sticky
on the directories, then new directories are created group cvs, and
owner is not important. Is that right?
Yes.
This is true for GNU/Linux, AIX, and Solaris.
The g+s bit is not needed for FreeBSD or NetBSD which has this behavior
by default.
See also 'Creating a cvs repository with pserver authentication'
http://www.korayguclu.de/index.php?file=linux.cvs.pserver.xml
Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCxySW3x41pRYZE/gRAotPAKCy9ittECD0XWxhvMnmjeSOxTKungCgkaNi
N9BSSqGJpnQiSrFHZb5y9q0=
=hpPV
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: I'm a newbie when it comes to compiling from source files, so i really appreciate any help you all can offer. Thanks again! X [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there a version of CVS that runs on FreeBSD? I only see versions for other Unix platforms, just nothing that explicitly says FreeBSD. Can anyone help? Just use /usr/bin/cvs as found on all FreeBSD distributions. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCwYII3x41pRYZE/gRAvv8AKCeRIn+tJd7mDgpTgfKQxqQlvLX0gCePl/0 H5TDo8Uo0mY/c0XHncbS1PE= =Jn5q -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FreeBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: Is there a version of CVS that runs on FreeBSD? There are many such versions. FreeBSD has been using cvs for development for many years. I only see versions for other Unix platforms, just nothing that explicitly says FreeBSD. Can anyone help? Any of the current versions on cvshome.org will work. Any of the current versions of cvsnt.org should work. You could also just use the version that FreeBSD provides. Experimental CVS releases may be found in /usr/ports/devel/cvs+ipv6 and /usr/ports/devel/cvsnt for FreeBSD. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCwYGL3x41pRYZE/gRAoSFAJ0Ts8xVnDH/P9xcGDrmuJnk+nwKCACgtfYg 9MwrS9kbAwYzGDsrgSiBPqE= =AdTT -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian Opificius [EMAIL PROTECTED] writes: Larry Jones wrote: Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. Yep, that's what I am/was doing. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. How can I maintain this level of integrity without pserver: keeping the repository itself inaccessible, while allowing write access through cvs? Using ssh in a restricted execution mode in general and for restricted execution of CVS is discussed in many places. I suggest you may find more reading useful... try these documents: http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html http://www.prima.eu.org/tobez/cvs-howto.html http://www.informatimago.com/linux/chrooted-ssh-cvs.html You may also find other documentions via your favorite search engine. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCwF2X3x41pRYZE/gRAv1sAJ0e08Qbt74VqXR4ELjguqFkoruPPwCdHKna u9OpZ7vumWiDN1fHzzEFa/s= =sqVv -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Recovering from Attic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Jackson [EMAIL PROTECTED] writes: Ok, if there is a directory in a project that had three files in it and they were all removed to the attic with cvs rm at different times and you want to recover all three files (say 3 could be 100+ files in some cases) but they all have different versions on them. How could you check the version just before the version that was marked as dead and moved to the attic? I did manage to recover something that had been tagged, but in this case many of the files would not be tagged in a version. One method is to checkout by datestamp and then tag files that you see and like with some tag (say recovery-tag), then use that tag to do the recovery: cvs update -A cvs update -jHEAD -jrecovery-tag There are other ways to get there, but most folks have some conception of the time when a particular file was okay. If not, then use cvs2cl or some other logging tool to get the dates into a file for you to consult. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCpx193x41pRYZE/gRAnidAKDWTiPhcM0c/TPrcDh4F+uAYIs0GQCfQwgI loShhKqujYoorYF6F4ll9Bk= =6X2O -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs 1.12.9 and new loginfo format
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Spiro Trikaliotis [EMAIL PROTECTED] writes:
I just upgraded to 1.12.9 (from 1.11.x) and I am a little bit confused
about the new loginfo format.
My current loginfo looks like:
DEFAULT Mail -s %1s [EMAIL PROTECTED]
Now, I've read
https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_18.html#SEC188 and
added the 1 as suggested there.
Anyway, I I do not quite understand how to go from here. :-( What must I
add to my loginfo line to make it behave like it used to behave with
1.11.x? I don't get it right from
https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_18.html#SEC192.
From my understanding, changing the line back to
DEFAULT Mail -s %s [EMAIL PROTECTED]
(that is, removing the 1 again) should do the trick for me. Anyway, I
am confused if this is the right step, or if there are any side-effects
I do not foresee yet?
Read https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_18.html#SEC188
Add the line 'UseNewInfoFmtStrings=yes' to CVSROOT/config
Use:
DEFAULT Mail -s %p %s [EMAIL PROTECTED]
and you should get something that approximates your old behavior.
Without accidentally trying to send e-mail to e-mail addresses you did
not expect when the bare %s would otherwise be sent as multiple
arguments and only the first would be in the subject line.
However, you may wish to consider something like:
DEFAULT Mail -s %p %{sVv} [EMAIL PROTECTED]
or you could write a wrapper script that generates the subject line
that you desire and is passed the %p and %{sVv} arguments separately.
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCo9Nq3x41pRYZE/gRAqqLAJ9gjvisomA3Dx4sJNJMTyVavAmnbACgpL7v
osF2nAmJX7sxOAgahOP5iCY=
=OcfP
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help: Importing whole directory to local machine from source forge site.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 prithisd @yahoo.com [EMAIL PROTECTED] writes: Hai, I am facing problem in downloadibg the whole directory structure from, http://cvs.sourceforge.net/viewcvs.py/translate/po/ Help me please. Why is this our problem? Go to http://translate.sourceforge.net/ and read. It should lead you to the page: http://sourceforge.net/cvs/?group_id=91920 that gives you the commands: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/translate login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/translate co -P \ translate/po you need to do the job. If you have problems, contact the project folks for that project on sf.net. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCn04R3x41pRYZE/gRAopbAKC2Bpywn4GIftSQVGPnjouEy0dlVgCgqTd1 RaT2Fn/8knJU4C1vYKr4Pe0= =qj1Y -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: selective write access in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mainak Sen [EMAIL PROTECTED] writes: Hi, Can someone help me with the solution to the following problem ? I want to selectively give write access to some subdirectories for some people. How can this be done ? Thanks a lot in advance, Mainak Adapt cvs_acls to your needs or write your own commitinfo trigger script. Documentation: https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.html?rev=HEADcontent-type=text/html Source: https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFClkE03x41pRYZE/gRApJpAKCBbU+FwQIQZb1YdiXtbT3BLM+NcwCgtyrW uUAGeGgpku0WrJpaw3iAKxU= =FC/G -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs verifying log message format per branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 vik [EMAIL PROTECTED] writes: I searched for and found a post on exactly this same topic on this group, and though it was helpfull, I couldnt figure out the technical details. So could someone please help me out? I am looking for a way to require a certain cvs log format --per branch--, For example, I want to require a format like Bug Id: digits in our production release branch, but not in the main branch. Here's what i found in the other post i read: The documentation about the verifymsg trigger seems to only allow this kind of restriction per module. I suppose that if I had the branch name available in the verifymsg trigger it would be easy to do. Is there a way to get at this info ? Like in the commitinfo trigger, where you have a list of the files to be committed, and so can ask of each file (with cvs status) which branch it is in? . The verifymsg script for your module is run once per directory after the commitinfo script is run. For client/server operations, it is run from the server-side directory that contains a copy of your files that are being committed. So, if you run a 'cvs -n status' command, you should be able to parse the 'Sticky Tag:' lines. (You need the '-n' switch so that you will not run into lock contention problems in the repository.) If your verifymsg script runs: cvs -qn status | grep '^ *Sticky Tag:' | sort -u The line will contain the branch information for you to separate out fairly easily using PERL or sed or awk ... depending on what else your script needs to do. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCk1A/3x41pRYZE/gRArBUAJ9tGEwhkYK9FgjIw90uXaxYZL6PTQCfTndr QJP8brRTGTZglpMCgZzwzHs= =fAYC -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: old cvs version needet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have no idea what you mean by 'case' commands in cvs or Netbeans. I suspect you are running into an error that is not directly related to cvs and may instead be related to your command environment. As to your problem with cvs 1.11 (which is ancient), you appear to be running into a problem where your system has the include files, but not the libraries for gssapi or kerberos. You probably either need to install the rest of that stuff or disable cvs from using it. ./configure --without-gssapi --without-krb4 However, I can assure you that that version of cvs did not have anything going by the name 'Case' in it. -- Mark pginfo [EMAIL PROTECTED] writes: Hi all. We are using cvs from long time (it is great software, thank you!). At the beginning we installed cvs server (v. 1.11) on linux mandrake and it is working till now. We need to change the OS to FreeBSD (we need to change the hardware). After installing the FreeBSD 5.4 we usend FreeBSD ports to install cvs. All was ok and we installed the version from ports (1.11.17). But we found problem by using this cvs version with our development toos (we are using old java based NetBeans 3.2 and it is not possible to change it for now). We found that Netbeans needs the case cvs-commant to work, but it is not supported in cvs 1.11.17 (we are not cvs nor freebsd experts). In case we try to checkout the repository we receive from NetBeans: unrecognized request `Case '. The next step was to change to cvs 1.11 . We got the source from cvshome.org and try to compile this version: ./configure make and we receive: cvs1# make making all in lib making all in zlib making all in diff making all in src gcc add.o admin.o buffer.o checkin.o checkout.o classify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o expand_path.o fileattr.o find_names.o hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o scramble.o server.o status.o tag.o update.o watch.o wrapper.o vers_ts.o subr.o filesubr.o run.o version.o error.o zlib.o ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a -L/usr/cygnus/kerbnet/lib -lgssapi -lkrb5 -lasn1 -ldes -lroken -o cvs /usr/bin/ld: cannot find -ldes *** Error code 1 Stop in /usr/mysrc/cvs/cvs-1.11/src. *** Error code 1 Stop in /usr/mysrc/cvs/cvs-1.11. My questions: 1. Can I enable case support in cvs 1.11.17 2. If it is not possible, what is the latest cvs version that supports case. 3. How to correct this erro by compiling cvs 1.11. Many thanks in advance, ivan. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCkYeT3x41pRYZE/gRAko0AJ9mTrwB2KE36z1qrL/wRCLdhYUKlgCfWo/n D/2eBcOdRI44fgy1EB+usUY= =ImnK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: old cvs version needet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 pginfo [EMAIL PROTECTED] writes: thanks for answer. I searched NetBeans.org for solution of my problem and found this one : http://www.netbeans.org/issues/show_bug.cgi?id=39919 Ahhh... cvs 1.11.12 is the one where the Case request-type was removed: News entry: |* Server support for case insensitive clients has been removed in favor of the | server relying on the client to preserve the case of checked out files, as | per the CVS client/server protocol spec. This is not as drastic as it may | sound, as all of the current tests still pass without modification when run | from a case insensitive client to a case sensitive server. This change | disables little previous functionality, enables access to more of the | possible namespace to users on systems with case insensitive file systems, | fixes a few bugs, and in the end this should provide a major stability | improvement. src/ChangeLog entry: |2004-02-02 Derek Price [EMAIL PROTECTED] | | Continue removal from server of handling of case insensitive clients. | | * cvs.h: Remove extern declaration of ign_case. | * ignore.c (ign_case): Remove declaration. | (ign_name): Remove support for ign_case. | * server.c (serve_case): Ditto. | (requests): No longer support the Case request. | * rcs.c (locate_rcs): Remove reference to GLOBAL in function header | comment. | You should be able to use cvs-1.11.11 which is at least a bit newer than the ancient cvs 1.11 version. It is obout NetBeans 3.6 ( my version is very old compared to this one), but I have the same problem. In this bug report I see the solution for this NetBeans version, but not for my one. I know, my version is very old and I do not expect some one to correct NetBeans v 3.2 to solve the problem. Also all is working by me with cvs 1.11 and I try to downgrade my cvs server version to 1.11. Is it possible to run cvs server with more debug info to find witch is the bad request? Also I ran : ./configure --without-gssapi --without-krb4 But it do not resolve my compile problem. After make I receive : . gcc -I. -I.. -I. -I../lib -DHAVE_CONFIG_H -Ino/include -g -O2 -c error.c gcc -I. -I.. -I. -I../lib -I../zlib -DHAVE_CONFIG_H -Ino/include -g -O2 -c ./zlib.c gcc add.o admin.o buffer.o checkin.o checkout.o classify.o client.o commit.o create_adm.o cvsrc.o diff.o edit.o entries.o expand_path.o fileattr.o find_names.o hardlink.o hash.o history.o ignore.o import.o lock.o log.o login.o logmsg.o main.o mkmodules.o modules.o myndbm.o no_diff.o parseinfo.o patch.o rcs.o rcscmds.o recurse.o release.o remove.o repos.o root.o rtag.o scramble.o server.o status.o tag.o update.o watch.o wrapper.o vers_ts.o subr.o filesubr.o run.o version.o error.o zlib.o ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a -Lno/lib -lgssapi -lkrb5 -lasn1 -ldes -lroken -o cvs /usr/bin/ld: cannot find -ldes The above indicates that it is looking for libdes.* as well as libgssapi.* and libkrb5.* in your environment and for some reason, you do not have those libraries available. The generated Makefile fles should not be generating those references if you did use the --without-gssapi and --without-krb4 flags. If you want more help, you should probably try capturing the output of the conifgure command itself. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCkbRj3x41pRYZE/gRAhmPAJ9Race+CzD7HPeclqhJfMkQoDiUsACcDMdi 5DkdlCaRFNo5FzlTi5SOZVo= =Cd0P -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Annotate or FORCING users to comment their checkins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S I [EMAIL PROTECTED] writes: Is there any way to force the users to comment or annotate their commits or checkins? Yes. via 'verifymsg' read https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC167 I know by default the -m comment goes here the system asks them to provide a brief comment, however, this can easily be bypassed. Can a template be set up or is there anyway to do this through the Admin level? Yes. Read https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC178 -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCiluL3x41pRYZE/gRAqEVAKDg0r3dEXzi+o3V+YJtqIrA/JvfCQCfS2DA 49pVnaWvNKBUpM6tcQI8MmM= =MKIU -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Satishkumar [EMAIL PROTECTED] writes: Can any one help in fixing this error. please cvs commit -m MICS Id:104226 \nDescription:adding new files ehelp.xml (in directory E:\en-US) cvs [server aborted]: received abort signal cvs: hash.c:312: findnode: A ssertion `key != ((void *)0)' failed. *CVS exited normally with code 1* we are using CVS version : 1.11.1P1(Client server) Upgrade to a more recent version of cvs. 1.11.1p1 was released in on April 27, 2001. You will find cvs 1.11.20 which was released on April 18, 2005 is likely to have a great many bugs fixed from the version you are presently using. You may download from https://www.cvshome.org/ and install. You may find it desirable to do a 'cvs init' after the install to add a few new files to the CVSROOT directory. Everything is fully backward and forward compatible in the cvs 1.11.x STABLE release line. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCiw2P3x41pRYZE/gRAvfAAKDCIakNLDmwBclaRO3Olnqd8cn4LACgjJvD lBvKKxJrnWT+nFoTDgjXUhQ= =TdJA -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs init on pre-existing old repository ok?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bulgrien, Kevin [EMAIL PROTECTED] writes: The original question was: A user did a cvs init on an existing repository. Is this generally safe, or might it be advisable to go back and check for differences against a backup? A 'cvs init' is always a safe operation modulo the fact that it will rebuild your CVSROOT administrative files (ie, do an update of them). For your purposes it would be the same as if you had done a 'cvs add' of a new file in CVSROOT and committed it. If you had uncommitted changes to files in your repository, you were asking for trouble in any case. CVS version is 1.11.17 http://lists.gnu.org/archive/html/info-cvs/2004-05/msg00050.html presumably contains an applicable answer: The 'cvs init' should only add files that are not already present but are needed by cvs. ... The 'cvs init' function should not do anything bad to your files unless you happen to have files in the $CVSROOT/CVSROOT that do not match the top-of-tree version in their corresponding ,v file in the checkoutlist. It is probably a good idea to create a test copy of the CVSROOT directory into another repository and run the 'cvs init' command to see what it does to your test setup before you do the real thing. Good luck, -- Mark It does appear that one needs to check a backup in order to be sure since the full context of the cvs init operation is not known. I suppose that depends on your level of paranoia. You really do want to do a 'cvs init' whenever you install a new version of cvs in any case. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCiw553x41pRYZE/gRAqQeAKCbW31WEgZ+4Ytyzj8dRTk2Rp3A2gCgmgIs /YbPwFyRRst4YvS01d2uBY4= =oq6q -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Permission Denied for 'other' users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
farseer [EMAIL PROTECTED] writes:
thanks for the response. I am not well versed in the unix/linux
commands. as such, i am wondering if you may be able to assist further:
1) How can i create a group?
This varies by operating system. The 'man group' command should help you
find documentation you need. It could be as simple as adding a line to
the /etc/group file, running the groupadd command or modifying an NIS
or LDAP database somewhere else.
2) How can i add users to that group?
The same command that specifies how to create a group will probably give
you hints as to how to add members to it.
You should probably consult with your system administrator to look at
the vendor documentation to ensure you do not do something wrong.
3) How dp o set all files in the CVS repository as owned by the newly
created group?
You will want to look at the chgrp command (which may have a '-R' option
to impact all files and directories on the command line recursively,
otherwise you will probably end up using the find command with the -exec
option being a chgrp command).
You may also wish to make all directories set-gid for some operating
systems (eg, something like 'find $CVSROOT -type d -exec chmod+s {} \;')
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCi5xT3x41pRYZE/gRAsTeAJ9lRduWE9hXpcywqjMD+Qwf4imjDACfSoiU
mKnYLGoG9wJC06jpyZc15U0=
=Pg6U
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question on branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please do not use HTML e-mail. Zeus Crisp [EMAIL PROTECTED] writes: Hello all, Hoping someone can help as I am a new users to CVS. I would like to know if there is a way to lock a specific branch to block commits within a CVS environment. We have an environment where we have several branches all created off main. I would like to have the ability to manage the branches indivdually where I can allow only certian users to commit changes to which ever branch. Currently I can apply a lock to the entire CVS repository but there are times when I don't want commits to occur in branch-A but there is no reason to block the commits to branch-B. I would also like to be able to dictate who can perform the commits. Read https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.html?rev=HEAD Fetch, configure and deploy: https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in?rev=HEAD You may find searching lists.gnu.org useful. Here is an interesting thread: http://lists.gnu.org/archive/html/cvs-utils/2004-02/msg00047.html Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFChviX3x41pRYZE/gRAh1wAKDhDP0IRyXystGoK527J19hIxN0aQCfT3Qa 0elk+gSxwG4L4Bci9q1CKFI= =T5Ht -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Terminated with fatal signal 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrice Durosay [EMAIL PROTECTED] writes: I installed cvs prerequisite packages on a solaris 8 server : diffutils-2.8.1-sol8-sparc-local.gz rcs-5.7-sol8-sparc-local.gz cvs-1.11.19-sol8-sparc-local.gz All you should have needed as cvs-1.11.19-sol8-sparc-local.gz The diffutils and rcs packages should only be needful if you are planning to run ViewCVS or some other add-on. Created the empty directory tree of my application Initialized cvs [EMAIL PROTECTED] $ cvs -d /dat/cvsroot init $ ll drwxrwxr-x 3 cvsuser bioinfo 1024 May 11 14:54 CVSROOT drwxrwsr-x 4 durosay bioinfo 512 May 11 17:27 Dataflows Checkout the CVSROOT, updated the CVSROOT/module file and commited it. OK. Tried to import my application via ssh with CVS_RSH=ssh [durosay @workstation Dataflows]$ cvs -d :ext:durosay @server:/dat/cvsroot import -m Import Sources Dataflows Durosay V2_0 Terminated with fatal signal 11 Core dumped; preserving /tmp/cvs-serv23418 on server. CVS locks may need cleaning up. Did I forget something or is it a bug ? Core dumps are almost always bugs of some kind (the only exception being when you ask for one explicity). Is there an other way to enter a new project in the repository ? You sould use a series of 'cvs add' commands. First for the directories and then for the files of those directories. Can somebody give me some clue ? What does the core file say? Download a gdb (http://sunfreeware.com/programlistsparc8.html#gdb) ftp://ftp.sunfreeware.com/pub/freeware/sparc/8/gdb-6.0-sol8-sparc-local.gz and use something like ssh server cd /tmp/cvs-serv23418 gdb /usr/local/bin/cvs core bt to see what you can see. Thank you by advance. Patrice Durosay Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCg6Fm3x41pRYZE/gRAuxRAKCSZGcNNmuYTfsgtF+dAU4hnybqbwCdF+Cv 3wY0YVrrgAx85rq+tt33Bo0= =2sJB -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: hello, everyone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fei Li [EMAIL PROTECTED] writes: How to get a CVS server and client web site http://cvshome.org http://viewcvs.sourceforge.net -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFChAhj3x41pRYZE/gRAg77AJwKnO6V/8gnsIrtYdhD+92P8D2ZZACfWnyI mzlT1BFQ8Q8jWPpcjq96dc4= =ygE8 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can't checkout to my C: root directly *PANIC* Admin Files Missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S I [EMAIL PROTECTED] writes: Do I set this value on the server side? I'll look at it. Thanks You will wish to look and see if it is set by checking out the CVSROOT/config file from the repository. Read https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC184 If you see that you are indeed configured to use TopLevelAdmin=yes, then Arno Schuring's analysis that you are unable to create and populate a C:\CVS directory is likely the root-cause of your problem. Good luck, -- Mark Steve Original Message Follows From: Mark D. Baushke [EMAIL PROTECTED] To: Arno Schuring [EMAIL PROTECTED] CC: [EMAIL PROTECTED], info-cvs@gnu.org Subject: Re: Can't checkout to my C: root directly *PANIC* Admin Files Missing Date: Tue, 10 May 2005 15:03:47 -0700 References: [EMAIL PROTECTED] Arno Schuring [EMAIL PROTECTED] writes: I'm not sure, but I might have (at least) a clue for you... Hi I've tried 4 or 5 different Windows command-line versions of cvs.exe from (1.10.5 to 1.11.20). Created a folder called cvs directly under C:\, pointed the path stmt to it. Created Home=C: and CVSROO envrionment variables, etc and successfully logged in to our linux repository where CVS is kept. Note that you say created a folder called cvs directly under C:\... If I check out any of our CVS modules or projects from the main respository to any subfolder of my drive C: everything goes smoothly. However none of the versions of CVS I tried allow me to directly check out a project to the root. So when at the dos prompt and I type C:\cvs co -P newproj I get these bizzare errors: cvs checkout: in directory .: cvs [checkout aborted]: *PANIC* administration files missing I think cvs treats the 'cvs' dir found as its own administrative dir. It then fails because it expects CVS/Repository and CVS/Root to exist, which obviously don't. Remember that windows' filesystem is case insensitive... I'm not exactly sure of this, though: I fail to reproduce this on my machine (though it is linux, not windows): Note: the 'TopLevelAdmin=yes' item in CVSROOT/config controls if a top-level 'CVS' administrative directory should be used. If your repository does not specify that option, then you won't care if there is a 'CVS' directory in your root or not. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCgZt93x41pRYZE/gRAvgIAKCsf4fiMe7ENDYpiAYwHA+sx4xH6wCeIHxt DS4TqqrTRelCk7tKOqUl+ew= =fVed -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can't checkout to my C: root directly *PANIC* Admin Files Missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S I [EMAIL PROTECTED] writes: OK, topleveladmin on the server is set to NO. Should it be set to yes? It should be set to do what you intend to see done. The default is NO. But per Richard or Arno, I renamed the cvs subdir (to mycvs) and I'm fine now checking to the root, however, a new problem has come up: if the projx already exists on the root when I originally did cvs co -P projx, re-executing the command a 2nd time in a row or also running will prompt me to delete the projx before proceeding, but if I CD into the projx and do cvs update projx or . dot, then I'm fine. Is that normal? Well, I don't use Windows for anything myself. Other folks will have to tell you what is normal or not. Here's the new error msg: ... cvs checkout: move away projx/help/ja/SubAccount.htm; it is in the way C projx/help/ja/SubAccount.htm #my comment: looks like it checks it out though anyway it just likes to complain... ... and so on and so forth about every file that already exists. This would seem to indicate a problem with the case of your file names. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCgmoR3x41pRYZE/gRAuEKAJ0dmPPjyyUG5cIC/TN9brqPKW/JwACgkmz2 RusiqEX86imeMucssASdhQA= =HhCx -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: branches and merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arno Schuring [EMAIL PROTECTED] writes: Venkatesh, Vijay [EMAIL PROTECTED] writes: I guess this is a fairly often asked question but just wanted to run this by everyone to get some feedback first. (am referring to the essential cvs guidebook) Have two branches app4 and app4_test, which I need to merge (and have done so already into the app4 branch, so merged from app4_test into app4) question1 : should i now tag app4 to signify the point at which the merge was made? It would be prudent to do this if you ever wish to do subsequent merges of the app4_test into the app4 branch in the future. However, if app4_test is to be left dorment, then the tag is not really useful. I haven't done much merging myself lately, but I always believed a branch-to-branch merge needed two states (tags) of the source branch, and the current state of the target branch. Or is both possible? If you are to continue doing branch merges in the future, it is usually desirable to tag the source branch so that you will know where to start the next time you do a merge to the destination branch (for purposes of discussion call this tag the 'merge-point'). Some people find it desirable to create a tag on the destination branch just before doing the merge to facilitate backing out all of the changes should it be determined that the branch was ill done (for purposes of discussion call this tag the 'pre-sync-point'). Some people find it desirable to create a tag on the destination branch just after the merge is complete so that they may be able to compare the tag on the source branch with the post-merge tag to determine the drift between the two branches (for purposes of discussion call this tag the 'post-sync-tag'). My question more clearly: why tag the target branch instead of the source branch? Does it really matter which one you choose? Typically, when one creates a new (child) branch, one will also create a branch-point tag (for purposts of discussion call this tag 'branch-point') on the parent branch. Consider the following work... It is time to create the child-branch from the parent-branch cvs checkout -r parent-branch -d parent module cvs tag child-branch-point cvs tag -b child-branch ... It is time to merge the changes of the parent into the child cvs checkout -r parent-branch -d parent module cd parent cvs tag parent-merge-point-1 cvs checkout -r child-branch -d child module cd child cvs tag child-pre-sync-point cvs update -jchild-branch-point -jparent-merge-point-1 ...resolve conflicts cvs commit cvs tag child-post-sync-point At some later time, if it is desirable to merge the changes of the parent into the child again, one does: cvs checkout -r parent-branch -d parent module cd parent cvs tag parent-merge-point-2 cvs checkout -r child-branch -d child module cd child cvs tag child-pre-sync-point-2 cvs update -jparent-merge-point-1 -jparent-merge-point-2 ...resolve conflicts cvs commit cvs tag child-post-sync-point-2 If at this time it is desirable to move all of the changes developed on the child-branch into the parent-branch, then something like: cvs checkout -r child-branch -d child module cd child cvs tag child-merge-point-1 cvs checkout -r parent-branch -d parent module cd parent cvs tag parent-pre-sync-point-1 cvs update -jchild-merge-point-1 ...the above command is the same as 'cvs update -jchild-branch-point .. -jchild-merge-point-1' ...resolve conflicts... cvs commit cvs tag parent-pst-sync-point-1 In the general case, the pre-* and post-* tags are not necessary. I urge you to one of the fine books on cvs (cf, https://cvsbook.red-bean.com/) to help you understand the subtle points... Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCgml73x41pRYZE/gRArtIAJ0S3hx1+hK5z2FH+RJAyHrmrTnkVgCg2Kjl PBPF+wRAwthbeXa8ObuUaUY= =4Vaq -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: branches and merging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Venkatesh, Vijay [EMAIL PROTECTED] writes: I guess this is a fairly often asked question but just wanted to run this by everyone to get some feedback first. (am referring to the essential cvs guidebook) Have two branches app4 and app4_test, which I need to merge (and have done so already into the app4 branch, so merged from app4_test into app4) question1 : should i now tag app4 to signify the point at which the merge was made? It would be prudent to do this if you ever wish to do subsequent merges of the app4_test into the app4 branch in the future. However, if app4_test is to be left dorment, then the tag is not really useful. question2: if i do tag app4 at this point, should other users checkout another version of the branch(at the tag point) or just up -r to that tag? In most cases, users are only interested in the branch, not in a snapshot of it at a partciular time. Users should therefore ignore that the nwe merge point tag exists and continue to use the branch. question3: if i do tag and users to get to that tag version, how do they make subsequent changes Users do not use the tag, they continue to use the branch. i.e. continue work on the app4 branch beyond that tag? Do i need to make another branch at this point, or ? Not applicable. This is where I got really confused in the documentation. Pls help., Thanks V This email may contain confidential material. If you were not an intended recipient, please notify the sender and delete all copies. We may monitor email to and from our network. This is a silly disclaimer. Consider lobbying with the appropriate authorities to have it removed as e-mail sent to a public mailing list is often archived in multiple locations and you have no chance at all of getting it deleted. We do not care if your employer does not trust you. All e-mail on this list may be monitored by anyone. Maybe they will learn something. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCgEvd3x41pRYZE/gRAowSAJ9TUzwwn72yDamUyivjn3t04MNAhgCgy1ps /5a/xVDtRPac0L1C9oGD9Y8= =Z/a1 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: SSH error: end of file from server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Wood [EMAIL PROTECTED] writes: for bash or other bourne shell variations use: CVS_RSH=/usr/bin/ssh; export CVS_RSH Thanks for that hint. I was doing it a slightly different way, which I thought was working as echo $CVS_RSH worked, but clealry CVS didnt like it! Some bourne shells allow you to combine the two statements into one: export CVS_RSH=/usr/bin/ssh in addition, you don't really need to use a full pathname for ssh, so export CVS_RSH=ssh is usually good enough. If you wish to determine if a shell variable has been exported into the environment, you may wish to use the 'printenv' command: printenv CVS_RSH Or, you could have your 'echo' command inside of a shell script that you run. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCgPeY3x41pRYZE/gRArafAKCX2ux+fWa6qgHPi11wKMdFe7nymACguSnn YJFnhB6U4h1+0jujhCjHXLM= =RJpD -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: SSH error: end of file from server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Wood [EMAIL PROTECTED] writes: I'm ignoring the problem on Windows for the time being because theres a separate mailing list for Tortoise CVS, but on OS X, where I'm running the normal Unix version of CVS, my OpenSSH client is at /usr/bin/ssh I've set the CVS_RSH environment variable to /usr/bin/ssh, /usr/bin and ssh, and none of them work. Now when I try to checkout I instantly get the following error: cvs [checkout aborted]: cannot exec: No such file or directory cvs [checkout aborted]: end of file from server (consult above messages if any) It's now trying to use SSH, which it wasnt before but cant find it?? Thanks Andrew First, for tcsh or csh shells use: setenv CVS_RSH /usr/bin/ssh for bash or other bourne shell variations use: CVS_RSH=/usr/bin/ssh; export CVS_RSH The command: cvs -t version should show you the command thas is being run remotely if you look for the 'Starting server: /usr/bin/ssh host.dom.ain cvs server' text. You should try a command like: /usr/bin/ssh host.dom.ain date to see if it will return the date to you. The most likely problem with 'cannot exec' is that the server is not finding the 'cvs' executable in your path. If you login to the server and determine that 'cvs' lives in '/usr/local/bin/cvs' then you could try on your client to use the CVS_SERVER variable For tcsh or csh shells use: setenv CVS_SERVER /usr/local/bin/cvs for bash or other bourne shell variations sue: CVS_SERVER=/usr/local/bin/cvs; export CVS_SERVER Now when you run the 'cvs -t version' command you should see some output that includes 'Starting server: /usr/bin/ssh host.dom.ain /usr/local/bin/cvs server' in the output. If all goes well, you will also see lines like 'Client: Concurrent Versions System (CVS) 1.11.20 (client/server)' 'Server: Concurrent Versions System (CVS) 1.11.20 (client/server)' or whatever version is actually running on the client and the server. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCf6c/3x41pRYZE/gRAtDTAJ40TfU4/biJ0AVsk+nBODUFHcazfACeNgzC K4l+lLN6Imap+SiTmnxV7g8= =kyhr -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 1.12 to stable, when?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Muller [EMAIL PROTECTED] writes: I need a fature in version 1.12 of cvs (post-tagging hook). For what it is worth, backporting that single feature to cvs 1.11.x should not be that hard for you to do... How stable is the 1.12 branch? Is there a published timeframe for when 1.12 will be stable? Does anyone on this distribution have an estimate? Releases of 1.12.x have been getting better and more robust. The CVSHOME team does try not to introduce new features that break CVS client/server interactions, but it is entirely possible that a new 1.12.x release will not immediately interoperate with some of the GUI interfaces and other feature add-on players out there (eg, DCVS, SmartCVS, WinCVS, eclipse, jcvs, tkcvs, WANdisco, et al) due to changes in output format. Derek has been floating the idea of moving to 1.12.x as the STABLE release of cvs and leaving 1.11.x behind sometime during this year of 2005. Maybe now is a good time to ask the question to this list. How many folks are already using cvs 1.12.x as their primary version of CVS and believe it is getting ready to have new features locked out and be moved to STABLE? We still have a few things in progress such as the newtags feature from Frank Hemer which I would like to see finished being added to 1.12.x before it becomes STABLE. Are there any other FEATURES that folks are interested in trying to submit to CVS in the near term such that we should delay moving to STABLE for a time yet? This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Copies of your message are archived at multiple independent locations. You may wish to consider contacting your legal department to rent them a clue that the real world use of broadcast e-mail to mailing lists is still used by employees of their company. It makes the company look bad to arbitrarily add such text to outgoing e-mail... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCewkp3x41pRYZE/gRAhVnAJ9uwoLED4Ver7Iiv5PdZNUAucGV+wCglZeD X+2WpFdBykbA5Fv/bpCf51E= =J+tF -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Validations in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Khurram Rashid [EMAIL PROTECTED] writes: I just wanted to know if there is any way in CVS to do validation check in, No, CVS is the wrong tool for your task. i.e. Developer checks out a module from CVS Developer makes some changes in the code. Developer then checks in the module as validation check in. At this stage by validation check in I mean that the module has to be reviewed by a validator before finally committing the module in the repository. i.e. Validator now checks out the module from CVS Validator validates the module Validator commits the module in CVS I suggest you look into using Aegis *http://aegis.sourceforge.net/) which is a transaction-based SCM system that addresses your described needs. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCe5hQ3x41pRYZE/gRAt/EAJ4r88SggF3z2yvX+EXSiNXQCKrKfgCgkLLo st5pNCW7pu6V2klg/hQv5sw= =h8LZ -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Question about binary distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur Barrett [EMAIL PROTECTED] writes: hello, i downloaded cvs-1-11-20.zip from https://ccvs.cvshome.org but i can=B4t find information about wich windows versions are supported. Is Windows 2003 server suitable for cvs server ? You may also need cygwin and other tools to run this version of CVS on Windows Server 2003. The Windows CVS client binary distributed by the CVS Project is compiled using Microsoft Visual Studio 6.0 and does NOT require Cygwin or any other software. The compiled EXE is statically linked, requires no DLL libraries and runs alone as is. Yes you are right - my mistake. I was thinking of the SSH support. Am I right in assuming that cvshome cvs requires cygwin for ssh support on windows? You should be able to use Putty by setting up your CVS_RSH environment variable without needing cygwin. Of course, you would need to download Putty and maybe Pagent as well, but neither of them require cygwin. I also think I saw a post recently somewhere saying that cygwin ssh is not windows 2003 compatible... That is something to address with the cygwin and/or OpenSSH folks as it is outside the scope of CVS dependencies. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCeTyt3x41pRYZE/gRAmqzAJ9Pmh1nY1u3hRQ7sVkQERT+zZNvfwCeJtPB CoMpi1tQXL3DCIzvk587W7w= =DZ1B -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: rcsinfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, You may need to see if CVS/Template is getting properly setup. I believe that a cvs 1.11.x server does not update that file via a 'cvs update' while a cvs 1.12.x server does update it. If you checkout a new tree, you should see the new template being used. Be advised that specifying /tmp for a critical file is probably not wise. You may wish to put that file into the CVSROOT directory itself. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCeTvf3x41pRYZE/gRAmR1AKCbFXP2OoJ6xCLglIPElVlrkzvWHQCgtnb0 IzHJhR1MyWIIeuo4IP7cAwk= =YB2D -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Arggg, I thought I had cvs worked out but I didn't
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 twoeyedhuman [EMAIL PROTECTED] writes: Okay, I used the advice to not install cvs as root, although for permission reasons i did do some cvs commands as root. I don't know why but I still can't commit files, even if i'm not root. This is what I did: 1) Unpacked/installed cvs as root Okay. 2) modified the /etc/bashrc to include the lines: CVSROOT=/cvs export CVSROOT This is probably not really necessary as any user could specify the CVSROOT in their own environment or on the command line. Around here is where I might have gone wrong: 3) did cvs init as root (worked) And now all of the files and directories under /cvs are owned by root and whatever account root was using at the time. This is not a good thing. You probably need to do at least this (as yourself) % id ...gid=nn0(name0) groups=nn1(name1),nn2(name2),nn3(name3)... choose one of the groups of which you (and your other users) are a part as the group for your /cvs repository. % chgrp -R nameN /cvs % find /cvs -type d -print |xargs chmod g+rwxs now all of the directories should have write permissions for groupN users. 4) did cvs checkout CVSROOT as root (worked) Sure. 5) remembered the thing I was supposed to do as normal user and did cvs checkout CVSROOT as normal user sean. This did not work, it said that I can't checkout into the CVSROOT directory. You need to be able to create lock directories in the /cvs repository and if it is owned by root and you are not a member of the group for the directory, this will be a problem. 6) did cvs cvs edit config as sean (worked) Hmmm... I would have expected an error message if 'sean' is a normal user. 7) did cvs cvs commit config as sean. this did not work as it said the file config didn't exist Summarizing the responses is not useful. Provide literal output from the cvs commands you are giving. Does anyone know how I should change my steps to get cvs commit to work? Have you considered reading the fine manual or any of the numerous books on the subject? -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCdFhh3x41pRYZE/gRApbQAKCQI93/g8U4/DwnbdlJlFO1jcJY1gCdHGJC MIEltu2zufd/dS721yZPyTs= =J2/w -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie: my own ssh key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Horst Jäger [EMAIL PROTECTED] writes: I need to know my own ssh-key to work with a remote cvs repository. I use a Win 98 Machine. Any ideas how I can get it? The known-hosts-file only contains the ssh-keys oft the remote-server. You probably need to generate a key and then you will also want to run an agent to hold your pass phrase. I suggest you start with a client that lets you generate a key. A list that might work on your platform may be found here: http://openssh.com/windows.html (these are non-commercial choices. If you want or have commercial choices, feel free to web search for them. SSH.COM might work for you.) For example, PuTTY read/download here: http://www.chiark.greenend.org.uk/~sgtatham/putty/ http://graphics.stanford.edu/infrastructure/net/putty.html Use PuTTYgen to generate a public/private key pair. Upload the public key to the remote server, use Pageant if you don't want to be prompted for your SSH key for every cvs command you issue and set your CVS_RSH environment variable to point to PuTTY. To be honest, if you are on win98, you will probably find http://www.cvsnt.org/ a better place to ask questions about the TortoiseCVS or WinCVS you are likely using and how it works with ssh. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCcTLZ3x41pRYZE/gRAjzQAJ9nj7u7n7a0LXhCUpEngK1WykzaBACfT7tM PVbhTdjysm9psZiw/8Ow1K0= =5Wtj -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Won't let me cvs commit config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 twoeyedhuman [EMAIL PROTECTED] writes: I see. So i can't edit things as root. But, can I still install cvs as root? I suppose you could. I would not recommend it. I usually verify the tarball's gpg signature, unpack the tarball, configure, build, and install software all as a non-privileged user (of course, that user often happens to have write permissions into the directories that 'depot' or 'stow' uses to make the files look like they are in /usr/local which does help). For security reasons, I recommend never letting user root run a cvs process. However, installing the software does not require that you actually run cvs, so do whatever you feel comfortable doing. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCcWDY3x41pRYZE/gRAne4AJ95qOxWynPPX4cWt0zQ/9z/pzI9iACfVDyf SAtzij1wbXTeiW5diM4fS3k= =hSf/ -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: different ssh key for each user?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 twoeyedhuman [EMAIL PROTECTED] writes: Is it possible to have a different ssh key for each user that logs into my cvs server? Yes, you just want to configure your server to allow logins which give each user their own home directory and therefore their own $HOME/.ssh/authorized_keys file. Then have them use the :ext: protocol with CVS_RSH=ssh so that they use cvs over ssh. You may want to use google to find out how to do restricted shells if you do not wish to grant general user login capabilities to those users. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCcaoJ3x41pRYZE/gRAmLyAKCerTG+pNFKwAp8aoG4+srd1B2eTgCeOiS2 gsR67o8aGVCmHICukFBU9+w= =xv/9 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: hook into cvs AFTER tag?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Muller [EMAIL PROTECTED] writes: I have a staging sandbox that I would like to keep up-to-date with the versions of my files tagged as release candidates (tag name: RC). My original plan was to put a command in the .taginfo file that does a cvs update in the staging sandbox (which was checked out with -r RC). This plan was foiled by the fact that .taginfo is called BEFORE the tagging occurs. Does anyone have any suggestion as to how I can perform some action server-side AFTER the tagging occcurs? I've had two ideas, both of which I don't like: 1) have .taginfo run something in the background that sleeps for some period that is longer than my tag command could ever take and then wakes up and updates the sandbox 2) have a cron job that updates the sandbox periodically I don't like either of these options because there's a delay and there is no user feedback when it's done. Does anyone have any better ideas? If you can move from cvs 1.11.x (STABLE) to cvs 1.12.12 (FEATURE), then you could make use of the posttag trigger. I urge you to look very carefully at the administrative differences between cvs 1.11.x and cvs 1.12.x releases and do lots of testing before you make the choice. Although we try very hard to make both STABLE and FEATURE work properly on all platforms, it is possible that you may find problems that you need to address with your configuration and use of CVS. Thanks in advance, -- Mike -- Michael Muller Senior Application Developer, [EMAIL PROTECTED], Inc. 2503 Walnut Street, Suite 301 Boulder, CO 80302 http://www.interactivate.com phone: 303-442-1740 fax: 303-442-1750 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. You are hereby notified that communication to a subscription alias such as info-cvs@gnu.org is NOT confidential as it is archived by many different systems and is visible via Google and Yahoo! search engines as well as others. Because of this, it is not possible to erase all copies of this message. If you need to use some kind of disclaimer for Sarbanes-Oxley, I suggest you get your legal department involved in the real world to come up with a disclaimer that makes sense when communicating with a public mailing list. Failing that, I suggest you consider gettting a personal e-mail address without those restrictions (eg, 'gmail.com' or 'hotmail.com') and use that for futher communications with info-cvs@gnu.org to avoid trying to place any restrictions on the dissemination of your e-mail. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCb9g73x41pRYZE/gRApULAKC35ZIg1v9sbIWggYjEON3vZj6m6wCcDDOF Md3idKxTNVP8wNs8zvpOFXA= =P/46 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Ledesma [EMAIL PROTECTED] writes: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: cvs [login aborted]: unrecognized auth response from localhost: cvs pserver: cannot open /var/cvs/CVSROOT/config: Permission denied It means that the /var/cvs/CVSROOT/config file on your system may not be read due to a permissions problem. One presumes that you have set CVSROOT=:pserver:hostname:/var/cvs on the machine, but that your /var/cvs/CVSROOT/config file has insufficient permissions to allow read by either root and/or the user doing the 'cvs login' command. Check your local filesystem permissions for / /var /var/cvs /var/cvs/CVSROOT /var/cvs/CVSROOT/config ... are any of those directories mounted via NFS? If so, then you may need to worry about the filesystem under the mount point as well. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCZ4/M3x41pRYZE/gRAmspAJ9ajMxiwPryxfEb/gkAk2pJNmyJHgCfeMJp 3bzThg7d9qmxS84vjgMcSOM= =GAB2 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
I was using CVS in local machine fine; running on top of Fedore Core 4.
my cvs version is 1.11.20 and after updating my system, I started
getting this error:
cvs [login aborted]: unrecognized auth response from localhost: cvs
pserver: cannot open /var/cvs/CVSROOT/config: Permission denied
I checked the permission and they looked OK, I'm not using NFS.
Here is the list of files from CVSROOT:
-r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist
-r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v
-r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo
-r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v
-r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config
-r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v
-r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers
-r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v
-r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo
-r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v
-rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history
-r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo
-r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v
-r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules
-r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v
-r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify
-r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v
-rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd
-r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo
-r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v
-r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo
-r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v
-rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags
-r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg
-r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v
The permissions look okay. You probably want to add the -t switch
cvs -t -d :pserver:localhost:/var/cvs login
to see if you can glean any more information about what is failing.
It could be some kind of bad argument to your xinetd.conf configuration
What do you have in /etc/xinetd.d/cvspserver ?
Does it look something like this?
--- cut here for sample /etc/xinetd.d/cvspserver ---
# default: on
# description: The CVS pserver is one of the most \
# insecure of protocols. It is not recommended \
# that you even consider using this on a network \
# where any potentially malicious users or viruses \
# might be able to attack it. Please consider \
# moving to use the :ext: method with CVS_RSH=ssh \
# in user environments as an alternative.
service cvspserver
{
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}
--- cut here for sample /etc/xinetd.d/cvspserver ---
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCZ7Y63x41pRYZE/gRAtmOAJ9x8nB5SzQg/73D5+S277Dt7Qyo7wCgt+pe
660j5OswJOQwE7zPHsXXW8w=
=YWKF
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
Mark D. Baushke wrote:
Manuel Ledesma [EMAIL PROTECTED] writes:
I was using CVS in local machine fine; running on top of Fedore Core 4.
my cvs version is 1.11.20 and after updating my system, I started
getting this error:
cvs [login aborted]: unrecognized auth response from localhost: cvs
pserver: cannot open /var/cvs/CVSROOT/config: Permission denied
I checked the permission and they looked OK, I'm not using NFS.
Here is the list of files from CVSROOT:
-r--r--r-- 1 cvsuser root 495 Apr 20 22:30 checkoutlist
-r--r--r-- 1 cvsuser root 699 Apr 20 22:29 checkoutlist,v
-r--r--r-- 1 cvsuser root 760 Apr 20 22:30 commitinfo
-r--r--r-- 1 cvsuser root 964 Apr 20 22:29 commitinfo,v
-r--r--r-- 1 cvsuser root 990 Apr 20 22:30 config
-r--r--r-- 1 cvsuser root 1353 Apr 20 22:30 config,v
-r--r--r-- 1 cvsuser root 602 Apr 20 22:30 cvswrappers
-r--r--r-- 1 cvsuser root 806 Apr 20 22:29 cvswrappers,v
-r--r--r-- 1 cvsuser root 1025 Apr 20 22:30 editinfo
-r--r--r-- 1 cvsuser root 1229 Apr 20 22:29 editinfo,v
-rw-rw-rw- 1 cvsuser root 84 Apr 20 22:30 history
-r--r--r-- 1 cvsuser root 1141 Apr 20 22:30 loginfo
-r--r--r-- 1 cvsuser root 1345 Apr 20 22:29 loginfo,v
-r--r--r-- 1 cvsuser root 1151 Apr 20 22:30 modules
-r--r--r-- 1 cvsuser root 1355 Apr 20 22:29 modules,v
-r--r--r-- 1 cvsuser root 564 Apr 20 22:30 notify
-r--r--r-- 1 cvsuser root 768 Apr 20 22:29 notify,v
-rw-r--r-- 1 cvsuser root 31 Apr 20 22:34 passwd
-r--r--r-- 1 cvsuser root 649 Apr 20 22:30 rcsinfo
-r--r--r-- 1 cvsuser root 853 Apr 20 22:29 rcsinfo,v
-r--r--r-- 1 cvsuser root 879 Apr 20 22:30 taginfo
-r--r--r-- 1 cvsuser root 1083 Apr 20 22:29 taginfo,v
-rw-rw-rw- 1 cvsuser root0 Apr 20 22:29 val-tags
-r--r--r-- 1 cvsuser root 1026 Apr 20 22:30 verifymsg
-r--r--r-- 1 cvsuser root 1230 Apr 20 22:29 verifymsg,v
The permissions look okay. You probably want to add the -t switch
cvs -t -d :pserver:localhost:/var/cvs login
to see if you can glean any more information about what is failing.
It could be some kind of bad argument to your xinetd.conf configuration
What do you have in /etc/xinetd.d/cvspserver ?
Does it look something like this?
--- cut here for sample /etc/xinetd.d/cvspserver ---
# default: on
# description: The CVS pserver is one of the most \
# insecure of protocols. It is not recommended \
# that you even consider using this on a network \
# where any potentially malicious users or viruses \
# might be able to attack it. Please consider \
# moving to use the :ext: method with CVS_RSH=ssh \
# in user environments as an alternative.
service cvspserver
{
port= 2401
socket_type = stream
protocol= tcp
wait= no
user= root
passenv = PATH
server = /usr/bin/cvs
server_args = -f --allow-root=/var/cvs pserver
}
--- cut here for sample /etc/xinetd.d/cvspserver ---
Good luck,
-- Mark
I really don't know what can be the cause? I changed my cvspserver
file to yours.
Did it help? (Mine was just an example I threw together, I was trying
to get you to provide information on your own configuration file.)
Here are my entries in services file ...
cvspserver 2401/tcp# CVS client/server
operations
cvspserver 2401/udp# CVS client/server
operations
cvs version 1.11.20
kernel version 2.6.11-1.1240_FC4
(Note: I have not yet played with FC4 myself...)
I don't see any 'cvs -t -d :pserver:localhost:/var/cvs login' output,
did I miss it?
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCaCnx3x41pRYZE/gRAsmtAJ4zZ1Y5tnAw5LAL61yBwLHV22ZUGACgwFmU
/Odhh313SR1r0bxyqogX7yc=
=p7us
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Klinke [EMAIL PROTECTED] writes: On Thursday 21 April 2005 17:27, Manuel Ledesma wrote: I was using CVS in local machine fine; running on top of Fedore Core 4. my cvs version is 1.11.20 and after updating my system, I started getting this error: Didn't CVS just move to the list of apps now under SELinux control? Could this be related? From a recent FC4 update selinux-policy-targeted-1.23.12-1 - * Wed Apr 20 2005 Dan Walsh [EMAIL PROTECTED] 1.23.12-1 - Fix dhcpc.te - fix hostname.te for targeted domain - Update from NSA * Added CVS and uucpd policy from Dan Walsh. I suppose that is possible. If so, then looking in http://www.nsa.gov/selinux/info/faq.cfm may be a good idea. You should also try reading this thread for ideas: http://lists.gnu.org/archive/html/info-cvs/2005-02/msg00274.html Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCaDoo3x41pRYZE/gRAlcqAJ966uy7a8wTL6mxli4FVYptRI+EggCfbGWw mwntH1fZ3+5SFmQTCS7tLHk= =mjIK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Locking the branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vijay SP. [EMAIL PROTECTED] writes: I have a requirement to lock a branch just before the release. I tried to browse thru the documentation and did get some idea. Has someone implemented it? You can do this with the contrib/cvs_acls file. Add 'deny|||branchname' to the appropriate restrict_log file. If so could you please share the details? Read https://ccvs.cvshome.org/nonav/source/browse/*checkout*/ccvs/contrib/cvs_acls.html?rev=HEAD Download https://ccvs.cvshome.org/nonav/source/browse/*checkout*/ccvs/contrib/cvs_acls.in?rev=HEAD Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCX+F83x41pRYZE/gRAocBAKCNSsYxh/rMReoB6XNjfEuMuGLwAQCgy6cw E3xH5T7n8XGU9p+A3zjyjCg= =CthY -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: alias module that checks out a particular branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Pierre Sevigny [EMAIL PROTECTED] writes: Modules are cool! Modules have problems as they may be changed over time making it difficult to recapture the state of a checkout from the past. Modules are not branched, so the same module file need to work for all possible branches of the repository. Someone suggested patches to modules to deal with branching once, but I lost track of that suggestion. Is it possible to declare a module that does a checkout of a branch, i.e. something like: product_A = product branch A product_B = product branch B No. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCXVuq3x41pRYZE/gRAjCnAKCbKqbJ8xvb6tTPO9sGoF31oZACIwCcCpAD 5w8tDH+ShgFhCsPkxXMmWD4= =DqQm -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: alias module that checks out a particular branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Pierre Sevigny [EMAIL PROTECTED] writes: Thanks, I guess tagging the module file at the same time of tagging the module would allow to keep track of the module evolution? Possibly, but cvs would not be able to use that version of the modules file unless you replaced the version on the trunk. -- Mark Would be cool to allow definition of modules per branches :) Thanks again for your answer, JP -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jean-Pierre Sevigny [EMAIL PROTECTED] writes: Modules are cool! Modules have problems as they may be changed over time making it difficult to recapture the state of a checkout from the past. Modules are not branched, so the same module file need to work for all possible branches of the repository. Someone suggested patches to modules to deal with branching once, but I lost track of that suggestion. Is it possible to declare a module that does a checkout of a branch, i.e. something like: product_A = product branch A product_B = product branch B No. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCXVuq3x41pRYZE/gRAjCnAKCbKqbJ8xvb6tTPO9sGoF31oZACIwCcCpAD 5w8tDH+ShgFhCsPkxXMmWD4= =DqQm -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCXWlD3x41pRYZE/gRAlsxAJ9ibTHAKEbWvh2TXxDdJ/o4Ic2MOACg2PbE ZZV3hjBzhg5GXFug/yxyxzs= =h+RK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: postwrite proxy server setup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] writes:
I am trying to enable write proxy functionality by using
CVS-1.12-11.But I have problem because primary servers will not
automatically push changes to secondary server although I has set
loginfo,postadmin,postwatch etc. scripts according to user manual,I have
added ALL rsync -gopr -essh ./ 192.168.1.1:/cvsroot/%p and ALL rsync
-gopr ./ 192.168.9.1:/cvsroot/%p into those files.
This will be wrong as '.' is the directory in the server's copy of your
modified tree and does not contain any ,v files. Also, you may find that
doing the backgrounding is best done inside of a shell script rather than
via the commit trigger line itself. You also need to worry about files being
moved to or from the Attic, so the --delete switch is your friend.
ALL background-rsync $CVSROOT/%p/. 192.168.1.1:/cvsroot/%p/.
where background-rsync may do something like this:
#!/bin/sh
exec /dev/null
rsync -rglop --delete --exclude '#cvs.*' -essh ${1+$@} \
/var/log/cvs-rsync.log 21 /dev/null
Note that you will want to use the CVSROOT/config 'LockDir=/some/path'
so that you don't rsync the cvs locks to your secondary, or you will want
to come up with some --exclude statements to use...
You may wish to take a look at the src/sanity.sh test cases that use
secondary updating $TESTDIR/sync-secondary ...
If I used ssh to commit some change to primary server,ssh tell me
permission denied,But I am using ext connection method(I don't know if I
can choose another connection method like pserver).
You may need to ensure that you are doing ssh-agent credential
forwarding. At present, the writeproxy stuff only works with :ext:
with either CVS_RSH=rsh or CVS_RSH=ssh, not with :pserver:
If I used rsh to commit changes directly to secondary
server/cvsroot,then those change could be submitted into primary server by
write through method,such as I have modified history.txt,v from version
1.1 to 1.2. later when I checked the same file in secondary server, I
didn't find any change for history.txt,v, instead I found a new file
history.txt was located at secondary repository there which already
contain latest change in this file.
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCUj933x41pRYZE/gRAji/AJ4sExGfquzTXS+wAMNjvKCQLan1vgCgyaIv
Rco5PXc0a87qz054j1aaDgI=
=pvf3
-END PGP SIGNATURE-
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Help on CVSup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nukala Srinivas Reddy [EMAIL PROTECTED] writes: I have installed CVS server and did some testing. Good for you. Did you install a cvs 1.11.x or a cvs 1.12.x version? Our requirement is to support development at multisite. Okay. I think CVSup can be used for it. Can anybody help me to install CVSup. Read http://www.cvsup.org/ ... if you are having problems, ask explicit questions and say what you have already tried to do and what host operating systems you are using for CVSupd and CVSup. Did you download and build the needed Modula-3 compiler? http://www.polstra.com/projects/freeware/ezm3/ Did you go through the FAQ step by step? http://www.cvsup.org/faq.html#obtaining Note that you may also find it desirable to read the FAQ about where to ask your questions as this forum is not really optimal for asking about CVSup even though some of the members are users. Regards Srinivas SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 The above statement seems an unlikely exaggeration of the press if they are making you use silly business disclaimer's like this one: SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCUspb3x41pRYZE/gRAhsHAKDCAOGhQ4brnzgCpjNHB2QJnn2r7gCgqVhG XtBLkxoniaiGai69i4dgSLg= =P/cq -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff statistics generation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Lewis [EMAIL PROTECTED] writes: As part of an evaluation I am undertaking, it is necessary for me to analyse the entire diff output generated by a CVS repository. I wish to look at statistics such as who is responsible for the percentage of changes to a file, to see what roles people have played in development of the project; whether they are specialising on one file, one module, or working more broadly. You may wish to start here: http://viewcvs.sourceforge.net/ http://cvsplot.sourceforge.net/ http://www.red-bean.com/cvs2cl/ http://www.akhphd.au.dk/~bertho/cvsgraph/ Some of the stuff that viewcvs can add to a MySQL database will be of interest to you. I'd also like some more advanced features, like how many lines people are adding, so I can try and see who was bug fixing and who was actually adding new content and such. One step at a time, however! Feel free to contribute if you add things like this. My Googling for any sort of solution has been less than fruitless, the closest I found was 'diffstat'. Well, diffstat has problems getting lost in changes to files that have a '-- ' leading comment prefix and does not understand the '-p' annotations, so you may want to normalize your diffs using something like one of the patchutils programs. I don't believe I am the first to have wanted to do this, and I don't believe I'm the only one that would release any programs or scripts I write to extract the data. Does anyone know of anything that could be helpful to me? Whatever platform the program is on, I'll find a way to run it! Otherwise, I guess it's time to open the Camel Book again and brush up on my regular expressions! Thanks every so much for any help guys, Chris Lewis Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCU26x3x41pRYZE/gRAnLRAJ9r9JPwpcRANp6jfIDu6DSS22fwfQCfXLDl /DWMS1HlzLIGaLjphAummwM= =nQdK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FW: FW: How to tell Pre commit script the exact File Name containing Spaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paras jain [EMAIL PROTECTED] writes: Thanks Russ, (Sorry Russ please ignore previous mail) You can test this by creating a script with the above as contents. Run it with args: a b b a. Then remove the quotes from the $@ ant try it again with the same args to see what (ba)sh does to the args. But my script is getting from CVS server is a b c not a b c That is why for I in $@ not helped me Let two files named as a and b c then CVS server send to my script is a b c not a b c ... I think I need to modify slightly in CVS code so that Pre-commit script will get files surrounded by double quotes but I am not known to CVS code ?? If anybody has the same problem or can guide me where to start... Pick up a copy of cvs 1.12.x and look at putting UseNewInfoFmtStrings=yes in your CVSROOT/config file along with changes to the various CVSROOT trigger files. Read https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_18.html#IDX319 for more details. (I believe this feature was introduced in cvs 1.12.6.) -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCTsoU3x41pRYZE/gRAqPaAKC+LZEc1TL6vM4iTM4xWVkTTK7i4QCgzCO0 GmTeV2lIf/CqkqzcIyPPZK0= =YdDf -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Repository on shared drive of dual boot system (WinXP and Linux)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FCC [EMAIL PROTECTED] writes: Be real here. You have a gmail account and still are playing games with the reply address? Why do you make life difficult for everyone who might want to reply to you? Anybody has any experience with such a setup? I have know of folks that used a mirror of the same repository on both Windows and GNU/Linux boxes with no problems which is close to equivalent. Problems only arise with the use of the scripting for the various commit triggers in the CVSROOT. You need to be careful how you setup your commitinfo, verfifymsg, loginfo triggers to work properly in both modes. I have a dual boot laptop that I use for developing code, and I have experimented with CVS for some time on WinXP and on Linux, but with repositories on WinXP and on Linux respectively. I would like to use one single repository regardless of whether I boot WinXP or Linux. Is that possible, or feasible at all? Sure, it is possible and with some care it should be feasible. However, you may find it is more sane to use CVSNT for both instead of just for the WinXP box in this case. Otherwise is may be difficult for you to have a consistent set of configuration files for commits. Note that info-cvs@gnu.org is not really about CVSNT questions, so you probably want to look into http://www.cvsnt.org/ for more answers. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCSu4U3x41pRYZE/gRArknAJ4+qTCJNJwqDxm/pA6/Q+0NlrxW4QCdFWtZ WYnSZJ8hu+AIEwDp1lthyLs= =ufti -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Editing Log Description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mary Lou RODRIGUEZ [EMAIL PROTECTED] writes: How can I edit the log description of the objects that have already been commited? Basically, some technical developers forgot to enter details during commit and I want to take note of the reference ID and Description of the checked-in object for a particular revision. Given a version x.y for foo.txt that needs to be updated cvs admin -mx.y:'This is the multi-line log message that was intended to be on the file' foo.txt See https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_16.html#SEC119 for details. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCS1Hx3x41pRYZE/gRAq4OAJ0Q2OIo6ekBGiHt4Ct/5E9ZNT6vQACfarA1 KM2J1OqTkt3rnpKCtcKJ8aY= =pRdd -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: verifymsg and branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Matt, Matt Doar [EMAIL PROTECTED] writes: I understand how verifymsg can be used to check the text in a commit message. The problems is that I'd like to have different checks for different branches, and there is no branch name variable that I can see to pass into a script called from verifymsg. The general problem is that you would need to send the branch for every file being committed as they may all be different with the current cvs implementations. So I went to see how scripts such as cvs_acls and activitymail get their branch information. cvs_acls seems to parse each directory's CVS/Entries file on the client, and activitymail seems to get it from the stdin for commitinfo. But I can't pass the %l variable (the name of the file containing the commit message) to anything but verifymsg and editinfo, and I can't pass the same stdin to verifymsg. Yes, %l would not be useful to you unless we also passed in all of the directory and filenames for the entire commit... I suppose a patch like that might be desirable and would be considered. Any suggestions? Well, given that verifymsg is run after all of the commitinfo triggers are run for all directories in the commit... You could collect the names of the branches for each of the files in the commit during the commitinfo phase of processing and then utilize that information in the verifymsg. You may use $CVS_PID as a way to create a unique instance of your commit in some central location, just be sure to clean it up in verifymsg when you are through with it. ~Matt p.s. I suppose a two step process of checking the message and recording the results for all possible branches somewhere, and then modifying cvs_acls to check for an acceptable message once the branch is known might work. Bit hokey though. Environment: cvs server 1.12.9, older clients and SmartCVS 4.0 -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCQyWD3x41pRYZE/gRAoArAJ94H8pi/XmNXot3KWfNV7C8GLJpqQCg4KnR 1tStJr/FWDqKh97o84h/qOQ= =n10P -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Todd Denniston [EMAIL PROTECTED] writes: This reminds me of conversations held earlier in the list. I think several of them ended with something to the effect of 'putting the /tmp/ or LockDir which cvs uses on a RAM disk should make the whole thing _much_ faster'. Yes. Our testing also found that using the SAN was faster than the Solaris 9 RAM disk solution. So, that is what we are using these days. If anyone is really serious about tuning and improving the performance of their own CVS installation, there should be nothing stopping them - From tweaking the sources for experimentation and running their own tests. If you instrument CVS and find a particular hotspot and then find a way to make that area more efficient without hurting the rest of the system, let the bug-cvs@gnu.org list know your results and your patch and you will likely find changes considered for inclusion in future versions of CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPvBl3x41pRYZE/gRAk3eAJ0ageE1b5X67SuvqubxXKXHUPHjIACgikBw Muqs+EjIyczfddfr7EZT8Aw= =2X8W -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: So - here are my questions/ideas - I'd appreciate comments to tell me whether I'm on the right lines: 1) As I understand it the tag data is the first of the 3 main data structures in the RCS file (tag, comments, diffs) and that when I do pretty much any CVS operation I rewrite the whole file - is this correct? CVS write operations on a foo.c,v repository file will write ,foo.c, and then when the write operation is successful and without any errors, it does a rename (,foo.c,, foo.c,v); to make the new version the official version. While the ,foo.c, file exists, RCS commands will consider the file locked. It is desirable to use RCS write semanitcs as many other tools out there (cf, ViewCVS) use RCS on the repository and want to obey RCS locking. 2) White space appears to be irrelevent in RCS files; so adding arbitrary amounts in between sections should leave files still fully compatible with existing RCS/cvs tools. Tools such as CVSup by default will canonicalize the whitespace between sections (although this may be configured). So, yes, whitespace is mostly irelevent between sections. 3) So the idea is that when I add a tag I add a bunch of white space after the tag (lets say 1KB of spaces split into 64 byte lines or similar); when I come to add the next tag I check if there is plenty of white space, if there is then instead of rewriting the file I just overwrite the white space with my new tag data; if there is no space then as I rewrite the file I add another lump of white space. This has the potential to more easily corrupt the RCS file if the operation is interrupted for any reason. 4) Whether dummy white space is added and how much is controlled by the existing size of the RCS file; so an RCS file that is only a few KB wont have any space added; that way this mechanism doesn't slow down/bloat small repositories. The amount of white space might be chosen to align data structures with disk block boundaries. 5) My main concern is to do with concurrency/consistency requirements; is the file rewrite essential to ensure consistency, or is the locking that is carried out sufficient? Does this make sense? It would be more robust to enhance CVS to use an external database for tagging information instead of putting the tagging information into the RCS files directly than to rewrite parts of the RCS file and hope that the operation didn't corrupt the file along the way. You may wish to consider looking at Meta-CVS as I believe that Kaz keeps a lot of the branching information outside of the RCS files already. See http://users.footprints.net/~kaz/mcvs.html for more details on Meta-CVS. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPaS23x41pRYZE/gRAjULAJ9RzLHw+gUDoMCbF0zjgmStBJIT9gCfUU83 K/TZMZdXbJx+BWVFaXGS0Jk= =fz6n -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: * Mark D. Baushke ([EMAIL PROTECTED]) wrote: Hi Mark, Thanks for your reply. Dr. David Alan Gilbert [EMAIL PROTECTED] writes: So - here are my questions/ideas - I'd appreciate comments to tell me whether I'm on the right lines: 1) As I understand it the tag data is the first of the 3 main data structures in the RCS file (tag, comments, diffs) and that when I do pretty much any CVS operation I rewrite the whole file - is this correct? CVS write operations on a foo.c,v repository file will write ,foo.c, and then when the write operation is successful and without any errors, it does a rename (,foo.c,, foo.c,v); to make the new version the official version. While the ,foo.c, file exists, RCS commands will consider the file locked. It is desirable to use RCS write semanitcs as many other tools out there (cf, ViewCVS) use RCS on the repository and want to obey RCS locking. OK, if I create a dummy ,foo.c, before modifying (or create a hardlink with that name to foo.c,v ?) would that be sufficient? I would say that it is likely necessary, but may not be sufficient. Or perhaps create the ,foo,c, as I normally would - but if I can use this overwrite trick on the original then I just delete the ,foo.c, file. I am unclear how this lets you perform a speedup. Is the problem that things are allowed to read the original foo.c,v while you are creating the new version? I am given to understand that many of the anicillary tools that surround CVS make use of being able to read a consistent ,v file at all times. 3) So the idea is that when I add a tag I add a bunch of white space after the tag (lets say 1KB of spaces split into 64 byte lines or similar); when I come to add the next tag I check if there is plenty of white space, if there is then instead of rewriting the file I just overwrite the white space with my new tag data; if there is no space then as I rewrite the file I add another lump of white space. This has the potential to more easily corrupt the RCS file if the operation is interrupted for any reason. The act of rewriting adding extra space would be performed using the existing mechanism (with just some extra add space created in RCS_rewrite); so that can't be a problem. Adding extra data to the ,foo.c, file during the normal write operation should not be a problem. So the issue is what happens if the interrupt occurs as I'm overwriting the white space to add a tag; hmm yes; Correct. Depending on the filesystem kind and the level of I/O, your rewrite could impact up to three fileblocks and the directory data. is it possible to guard against this by using a single call to write(2) for that? Not for all possible filesystem types. Is that the problem you are thinking of? Yes. Even worse things can happen in this regard if the filesystem is a 'stateless' one such as an NFS mounted directory (we keep advising folks against using them, but I know for a fact that they are still used). It would be more robust to enhance CVS to use an external database for tagging information instead of putting the tagging information into the RCS files directly than to rewrite parts of the RCS file and hope that the operation didn't corrupt the file along the way. Sure, seperating the tagging data out is much neater; but what I was looking for here was a simple speed up which didn't require anything extra and would be fully compatible with existing tools. And you are finding that existing tools torture the assumptions you are able to make about the CVS repository. FWIW: (In my personal experience) using a SAN solution for your repository storage allows you much better throughput for all write operations in the general case as the SAN can guarentee the writes are okay before the disk actually does it. Optimizing for tagging does not seem very useful to me as we typically do not drop that many tags on our repository. You may wish to consider looking at Meta-CVS as I believe that Kaz keeps a lot of the branching information outside of the RCS files already. See http://users.footprints.net/~kaz/mcvs.html for more details on Meta-CVS. If I was changing to another tool then I'd have a much larger set of tools to consider (e.g. subversion) but I'd rather stick with plain CVS if I can - I've got clients on lots of (weird) OSs that work via pserver and an infinite number of scripts built around CVS. Indeed. Part of the difficulty with CVS development has been worrying about legacy software assumptions. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPfR63x41pRYZE/gRAr5/AKCVOkIlgvWabSYXCJ10JbT6W7tMqACdFQs0 6WWc8Ig8hFISTOJK3IhGUB8= =PW+V -END PGP SIGNATURE
Re: Idea for reducing disk IO on tagging operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: * Paul Sander ([EMAIL PROTECTED]) wrote: Hi Paul, Thanks for the reply, Everything that Mark says is true. I'll add that some shops optimize their read operations under certain conditions, and such optimizations would break if the RCS files are updated in-place. What happens is that, if the version of every file can be identified in advance (using version number, tag, or branch/timestamp pair) then they can invoke RCS directly to fetch file versions, read metadata, and so on. This sidesteps CVS' overhead and can increase performance by as So are these tricks *never* performed by cvs itself? Never? Hmmm... well, the CVS from cvshome.org will not read a foo.c,v file while the CVS read-lock or a CVS write-lock is owned by another process. The real problem is dealing with filesystem errors while RCS is updating the ,v file. I would not trust that the RCS write manipulations will always fail in a safe manner. i.e. would my trick (if I can solve the interrupted write case) be completely safe with any use of cvs as long as you didn't access the files externally? I am not able to say that it would ever be 'completely safe' to do as you suggest. You would need to greatly harden the failure paths of CVS to ensure that the file being modified is not just discarded in the event of a filesystem error by CVS itself. I would not wish to attempt to do it myself. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPnPk3x41pRYZE/gRAi8hAJkBOVbkrD8oSF7/tn4BzFl6JWY5yQCfSKop 72vIMJsvjAoBlQA0NRhf25E= =dWOz -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: I only create the ,foo.c, file - I don't write anything into it; the existence of the file is enough to act as the RCS lock; if I can do my inplace modification then I delete this file after doing it, if not then I proceed as normal and just write the ,foo.c, file and do the rename as you normally would. You're forgetting something: The RCS commands will complete read-only operations on RCS files even in the presence of the comma files owned by other processes. Your update protocol introduces race conditions in which the RCS file is not self-consistent at all times. Actually, if you look closely, I believe that CVS will not do read-only RCS operations if a CVS write-lock exists for the directory. Of course, ViewCVS and CVSweb do it all the time as do many of the other add-ons. There's also the interrupt issue: Killing an update before it completes leaves the RCS file corrupt. You'd have to build in some kind of crash recovery. But RCS already has that by way of the comma file, which can simply be deleted. Other crash recovery algorithms usually involve transaction logs that can be reversed and replayed, or the creation of backup copies. None of these are more efficient than the existing RCS update protocol. Agreed. This is a very big deal. Dr. David Alan Gilbert [EMAIL PROTECTED] writes: FWIW: (In my personal experience) using a SAN solution for your repository storage allows you much better throughput for all write operations in the general case as the SAN can guarentee the writes are okay before the disk actually does it. But when you throw a GB of writes at them in a short time from a tag accross our whole repository they aren't going to be happy - they are going to want to get rid of that backlog of write data ASAP. I believe you will find that the performance knee for a commercial SAN that is well provisioned happens when you hit a 2GB of sustained writes. You are more likely to run into problems with bandwidth to the fiberchannel mesh first. For us, I seem to recall that the actual bottleneck is the creation of the /tmp/cvs-server$$ trees for a 'cvs tag' operation. So, you results will also depend on how shallow or deep your module hierarchy runs. Optimizing for tagging does not seem very useful to me as we typically do not drop that many tags on our repository. In the company I work for we are very tag heavy, but more importantly it is the tagging that gets in peoples way and places the strain on the write bandwidth of the discs/RAID. Sure, a conventional RAID can be very expensive to rewrite all of the files. It is certainly possible that a close look at CVS performance bottlenecks may find some places where improvements in throughput could be gained. However, I and not at all certain that your particular suggestion would be the best use of optimization time. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCPnkr3x41pRYZE/gRAtu0AJ4qNbP4WSN9C60hZsaBejYwYcbnDACdGsOZ RMw/SnkdG/mGOP2oyrdWnis= =lD1h -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS for Window cannot be a CVS server?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tuong Tran Vu Ngoc [EMAIL PROTECTED] writes: Note: Please do NOT send multipart/* or text/html MIME e-mail to the info-cvs mailing list. I have read in a ebook called Open Source Development with CVS 3rd edition that we cannot use CVS as a server on Window Platform? (only client) Is it right? Yes. You probably want to use the CVSNT (see http://cvsnt.org/) fork of CVS which has support for being a server on a Windows Platform. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCMVoj3x41pRYZE/gRAml1AKCfcTTYS2N8299QvcM+p1FLPI4nsgCgniRB jV4581KQier4RerqovbTEqY= =nJIS -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Mac CVS Client Recommendations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MoonsOfJupiter [EMAIL PROTECTED] writes: My command-line impared Mac-using workmates want to know what GUI CVS client they should be using. Some are using MacCVSX now. All are running panther. What do you think? There a wide selection from which to choose. In no particular order: MacCVS.org has a client that some folks like. I don't know if they have updated it recently or not. smartcvs.com has a client that some folks like. tkcvs will probably work if you want to use an X11 client CVSL may be useful to you http://www.sente.ch/software/cvl/ eclipse.org has a good client MacCvs Pro: http://sourceforge.net/projects/maccvspro/ might be interesting. http://lincvs.org/ has some fans. Some folks like to use a combination with their editor and a command-line CVS. Examples of this camp are: - BBEdit - Emacs For myself, I like using GNU Emacs plus /usr/bin/cvs as the interface. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCMVxy3x41pRYZE/gRAnOFAKCjWqn1MAs2pja7a9czxLn0cLVgHgCfbjLT DOo2SD5fGvcodoV67OA5+p8= =wEms -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Best Practices: How to remove corrupted CVS files?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Weiss [EMAIL PROTECTED] writes: I've been asked to migrate our CVS repository over to Subversion (hope that's not a dirty word here). Not at all. The svn community has lots of roots in CVS and is considered by many to be a likely successor. While running the cvs2svn tool, I got a list of a dozen or so files with the error filename is not a valid ,v file. These files are unrelated and obsolete (most have been abandoned or are in the Attic already), so losing them completely is not a concern. Okay. There are several modules in the repository, but none that cover all of the affected files. Naturally, that would make things too simple. :-) What would be the best way to deal with these files? Go in an resolve the RCS problems to make the files be correct... this may require access to backup tapes in some cases. I'm no CVS expert, so maybe I'm missing the obvious easy answer... Corruption of the RCS files is non-trivial in any case. Option 1 - Manually delete the files from the folders in the repository from the shell. I would suggest you try to avoid this approach if possible. You could just create a 'copy' of the repository for purposes of import that excludes these problem files, but it would really be a good idea to salvage as much as possible from those files. Option 2 - Create a new module that covers all of the files, attempt to check them out and recommit them in the hopes it'll fix the corrupted files? It is likely that the top-of-tree versions of your files are okay due to the way that RCS keeps files. Just checking them out and recommitting them will not help you recover the older versions that might be corrupt due to problems with the delta records in the RCS file. Option 3 - Run a sanity checking application that I've yet to find :) You probably wan this tool: https://ccvs.cvshome.org/source/browse/ccvs/contrib/validate_repo.in Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCMOBj3x41pRYZE/gRAojdAJ9f+C36zZM0PbSiPxZGKHM1MuD80QCfRJku tSqZfp8O2dFLRA9Brp0kWaU= =SCLu -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and tracability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Familie Moner [EMAIL PROTECTED] writes: I'm faced with the requirement to trace changes due to certain bugfixes, i.e. to answer questions like which files have been affected by change request 1234. Currently, the only way I can think of to answre question like this is using the taginfo mechanism. Are there any examples I could use? Other approaches? You could alter your CVSROOT/rcsinfo to provide a log message template with something like a 'request:' field and enforce good values via the CVSROOT/verifymsg trigger and have your loginfo trigger send e-mail or otherwise attach the desired information of the request found in the log message into your defect tracking system that attached the list of modified files to the request-id. This would let you query your defect tracking system for entry '1234' to obtain a list of files that were impacted on a particular date. Another approach would be to use something like the cvs2cl package to generate xml for all of the changes in a given release and collect the list of files needed from the entries with log messages that reference the interesting bugfix identifiers in a useful way to your own applications. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCKyEb3x41pRYZE/gRAqHgAJ401IbLhaxuvmhAu49ftt7zuYd9QQCggYUp 08L2n1P3Qe686QoQ/ZxlJbo= =pUS6 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: making cvs repository online using IIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rajeev R [EMAIL PROTECTED] writes: I have already a cvs repository set up in our office . I am accessing the cvs repository using set cvsroot=:pserver:[EMAIL PROTECTED]:2401:/cvsrepository Could any one tell me THE STEPS to make this existing cvs repository online USING IIS. Generally, folks use one of - ViewCVS (http://viewcvs.sourceforge.net/) - CVSweb (there are various versions use google to find one you like) - CVS Monitor (http://ali.as/devel/cvsmonitor/) to make a readonly view of the sources available. Most folks also use Apache for this purpose. You may wish to ask the http://cvsnt.org folks about using Microsoft IIS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCIqCk3x41pRYZE/gRAsYaAKC5fSK+VztekHzayw3GknsmYREo0ACffttx kdFQD3o+NjE/w1mkGFDcTqY= =PEqq -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pierre Asselin [EMAIL PROTECTED] writes: Mark D. Baushke [EMAIL PROTECTED] wrote: New imports are always on the vendor branch with -X and 1.2 is always dead. So, the trunk is no longer ever potentially broken. Hmmm, I see. I had read the 1.12 documentation at https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_16.html#SEC115 and it didn't occur to me that all the files are new during the initial import. Yup. So if you check out a trunk sandbox after the initial import -X, you get an empty ? Yes. I can see a new FAQ being born. How do you do the initial merge, with just one -jVENDOR ? Sure. cvs update -d -jVENDOR For future imports, something like this is more likely: cvs update -d -jVENDOR:yesterday -jVENDOR Here is the thread that discusses the new option: http://lists.gnu.org/archive/html/bug-cvs/2004-06/msg00173.html Hey, multiple vendor branches should work now. I have not tried it, but you may be correct. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCHoj63x41pRYZE/gRAuuxAKCfXcVW8B0CsbJwiTP5sURz48M3HgCeNQMP gVb4XZjRTb4YvvG4wtNgA+w= =dukG -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'checkoutinfo' trigger?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop [EMAIL PROTECTED] writes: For us, an equivalent to the 'commitinfo' which runs at checkout-time would be very useful. The trigger would behave the same - an exit code of 0 allows the checkout to proceed, and a non-zero exit code aborts the checkout. Are we unique in this requirement, or are there other people on this list who would find a checkout trigger useful? I have seen something like your requirement, but is was inverted. That is, I have seen some code that needed to be moved to a separate repository which had more restricted logins so that only a subset of users could access it due to contractual obligations between two companies to work on a common subsystem. In the case I have seen, it was felt that the separate repository was a requirement to avoid any possibility for holes in the source control system to be used to let unauthorized users into the system. It was also the case that strict controls were placed on where such restricted software could be checked out, so that no one could just NFS mount a checked out copy of the software and use it. In fact, software that did backups had to be done separately for such joint projects as well due to the fear of the company owning the IP that the joint development IP might be misused. This differers from your case where only a portion of the repository is restricted. I would think that the solution to your problem would be that the commit triggers for your new co-op code would open the umask for newly added directories and files to be 000 to allow anyone access to those files. If you do feel some kind of trigger on checkout is needed, you will need to consider: How does the new policy interact with the following add-ons? - CVS Monitor - CVSGraph - CVSPlot - CVSconnect - CVSsuck - CVSup - CVSweb - ViewCVS Is is possible for a non-authorized user to just go and look at someone else's checked out tree? Is it possible for a non-authorized user to go to backups of a tree and read those? If there is value to your proposed enhancement, you will probably also need to include some documentation that at least discusses the inherent dangers of assuming that the sources are 'secure' just because the cvs admin enables this proposed feature. I have no fundamental problems with adding a checkout trigger. It suppose it might let cvs administrators 'hide' things in CVSROOT more effectively if there is a need to do that. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCHLzg3x41pRYZE/gRArYrAJ97FuPuEVj/kKqP3mcoaEgnwdyJ+ACfSSly qYxHENjTuHbrOl13NslWikM= =PvfD -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'checkoutinfo' trigger?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim.Hyslop [EMAIL PROTECTED] writes: Mark D. Baushke wrote: [snip use-case] This differers from your case where only a portion of the repository is restricted. Interesting. Same idea, different subsections (as you say, an inverse of our requirements). I would think that the solution to your problem would be that the commit triggers for your new co-op code would open the umask for newly added directories and files to be 000 to allow anyone access to those files. Hmmm... this might work. This would require whoever adds a directory to also immediately check in a file, because commitinfo will run only when files are checked in. Before permissions are adjusted, if anyone in the other group tries a 'cvs update -d', or anything else that tries to recurse into the new directory, cvs will abort because it can't lock the directory. You could also run it from loginfo. loginfo is run for a newly added directory. If you do feel some kind of trigger on checkout is needed, you will need to consider: [lots of stuff] Thanks for those points to ponder. Of the 8 add-ons you mentioned, I'm only familiar with two (CVSweb and ViewCVS) - I'll have to familiarize myself with the others (if for no other reason to see if they would be useful for us :-) Heh. Yeah, there are lots of things that have been written by folks over the years to help maintain or collect the metadata of CVS out-of-band. I'll think on this some more, and if I come up with a more complete proposal I'll post it here for further discussion. Sure. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCHMk23x41pRYZE/gRAuKpAJ9z3bjk9fK7mOQ319wlPE5CYh4GbACgzN1g G7/BdhIzdk172wqlqj5ALgI= =npdQ -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS concept of time - time zone part 44!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: This has been talked about several times, so I said part 44! :) However something still does NOT make sense to me.. My sandbox and server are BOTH on the EST time zone, at least when I say date I get the EST time. However, when I issue a CVS command (tag, commit, etc.) on the server, the server shows 5 hour diff. between when the command is issued and a cvs report. Ex... On client (HPUX 10.20) sandbox date Wed Feb 23 17:30:14 EST 2005 On Linux box (Fedora) server date Wed Feb 23 17:30:20 EST 2005 On sandbox cvs rtag -F -r b_branchname t_tagname proj cvs history -Ta T 2005-02-23 22:30 + user proj [t_tagname:b_branchname] ^ UTC numeric timezone See what I mean? This would make sense if Linux box was set to UTC, but it's set to EST correct? CVS keeps time in UTC to allow for clients that may be in other timezones. It is always in UTC. User input of dates defaults to local time, but you may add a timezone explicitly to the datestamp if you wish. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCHQ1A3x41pRYZE/gRAhj2AKC5E2PFHngZcF9qdEdq2TYCPUdUswCdFlMO BXHkVK8XakPK7qpV/9Wov/M= =SEWS -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pierre Asselin [EMAIL PROTECTED] writes: Mark D. Baushke [EMAIL PROTECTED] wrote: Pierre Asselin [EMAIL PROTECTED] writes: ... It's important to understand that each import after the first *breaks the trunk* until the merge has been successfully committed. Note that if you are using cvs 1.12.x, you may find the -X option to be of interest as it does NOT put an import branch into the mainline directly. Instead, a dead version 1.2 is created on the first import. So files added by the vendor don't show up on the trunk, but in the meantime the trunk is still potentially broken. Suppose the vendor made changes to several closely related files, some but not all of which had been modified locally. New imports are always on the vendor branch with -X and 1.2 is always dead. So, the trunk is no longer ever potentially broken. Immediately after the second import, the two classes of files are no longer in sync on the trunk. The locally modified files are still at revision 1.2 and have only your changes. To pick up the new vendor changes in these files, it is essential to merge the import and commit a new revision 1.3 . Immediately after the second import, only files that you wanted visible on the trunk from the first import are visible, no new file is visible and new versions would need to be explicitly merged into the trunk. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCHWFl3x41pRYZE/gRAu/BAJ4jmHDBr45EXRSUOmlyqVfdJcBKtwCeOmS+ SdnacJKAdixwkklxP8CIS+A= =zQiH -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: vendor/local files in CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pierre Asselin [EMAIL PROTECTED] writes: ... It's important to understand that each import after the first *breaks the trunk* until the merge has been successfully committed. Note that if you are using cvs 1.12.x, you may find the -X option to be of interest as it does NOT put an import branch into the mainline directly. Instead, a dead version 1.2 is created on the first import. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCGtMv3x41pRYZE/gRAs11AJ94HYsp48nas1swaZuQhRcZg8DQxgCgnNr8 EMkWobH0Bct7dwMp/KM87+M= =HfG0 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Differences in 1.11.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamilton, Mark E [EMAIL PROTECTED] writes: This is a multi-part message in MIME format. Please do not send MIME encoded e-mail or text/html e-mail to the info-cvs list. We just upgraded our SoureForge intallation, which included a CVS upgrade from 1.11.5 to 1.11.17. Now our regression tests show that where a 'cvs update' command used to output: cvs server: Updating test1/rtest Now (and as of 1.11.13) it outputs Actually, as of 1.11.7, it outputs that checkout instead of server for you. cvs checkout: Updating test1/rtest (which is what used to be output when doing local repository updates.) This is not a problem, but I want to be sure that it is not indicative of some sort of build or configuration error on our server. There is nothing wrong. In fact, something is fixed. Excerpt from the NEWS file: |Changes from 1.11.6 to 1.11.7: | |... | |* In client/server mode, most messages from CVS now contain the actual |command name rather than the generic server. |... src/ChangeLog says this: |2003-08-27 Larry Jones [EMAIL PROTECTED] | | * history.c: 'P' is a valid record type and has been for a long time. | Add it to the comments, usage message, and, most important, | ALL_REC_TYPES so it gets recorded by default. | * server.c (do_cvs_command): Set global command_name to the real | command name rather than leaving it set to server. | * sanity.sh: Update to match. | (Reported by Dmitry Ryzhkov [EMAIL PROTECTED].) I hope this information is useful to you. Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCF+nH3x41pRYZE/gRAmK8AJ9NReMHTklZ4Rit9WQ3DwLTbzwO2QCgoxvi sMA28/rm4xGfWZokza/d2ng= =Qj8m -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FAQ-O-Matic pserver protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guus Leeuw jr. [EMAIL PROTECTED] writes: Hence I am looking at the pserver protocol, so I figured, it is a FAQ. Now depending how you interpret FAQ (asked or answered), I was right ;) It's apparently asked often, but https://ccvs.cvshome.org/fom//cache/446.html gives no answer :( Search the info-cvs archives and you might have more luck. The short answer is don't use it. Move along, this is not the protocol you are looking for... Can anybody tell me where the doc is? Can't seem to find it in the cvs1-12-11 branch... For HTML Cederqvist manual for cvs 1.12.11, look here: https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs.html For the client/server protocol, look here: https://ccvs.cvshome.org/source/browse/ccvs/doc/cvsclient.texi You should be able to find a doc/cvsclient.info file and a doc/cvsclient.ps -- these forms of the document describe both the pserver framework and protocol (as well as the kserver and server protocols). If you plan to read the document closely and you actually care about security, issue ear-plugs to your neighbors so that your screams will not distrub them too much. In general, my personal opinion is that the pserver and kserver protocols should be removed from the cvs sources completely. It is never secure to run the cvs executable as root which is required to use the pserver protocol. The cvs sources were never designed with security in mind and running them as root is idiocy. (Just say no.) You really want to consider moving to :ext: using the SSH transport. This allows end-to-end security and does not provide as much room for privilege escallation to arise. If you feel you must use pserver and are not yet using it, you should probably consider using some other source control system first. If you are using pserver, I hope it is on an isolated LAN with lots of firewalls and does not control any sources you really need to be kept secure. I also hope that you are making plans to transition away from pserver usage as fast as possible. Summary: Friends don't let friends deploy cvs pserver configurations... -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCDxIP3x41pRYZE/gRAiwuAJ9ftpS2nUin7Elfdk+BtNQxsBeJLACfd46W Cd5mD5+/FsrE+apvSb4R7zg= =CUO0 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FAQ-O-Matic pserver protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guus Leeuw jr. [EMAIL PROTECTED] writes: Hence I am looking at the pserver protocol, so I figured, it is a FAQ. Now depending how you interpret FAQ (asked or answered), I was right ;) It's apparently asked often, but https://ccvs.cvshome.org/fom//cache/446.html gives no answer :( Search the info-cvs archives and you might have more luck. The short answer is don't use it. Move along, this is not the protocol you are looking for... The hence above was indicating that I am writing a passwd command for the pserver stuff, as Jim suggested would be a nice feature... On dev, so far, no hard statement against doing this... If you think, I shouldn't be doing this, please state so, and I'll back out doing more important stuff... Larry and Derek would both need to agree with me that pserver needs to be killed before we could rip things out of the feature version. I doubt that will happen given how many folks still use pserver out there. There is also a CVSNT fork of CVS that has even more ways to 'authenticate' the client for server operations... they also have the command you are talking about writing. Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on boxes other than Windows.) Can anybody tell me where the doc is? Can't seem to find it in the cvs1-12-11 branch... For HTML Cederqvist manual for cvs 1.12.11, look here: https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs.html For the client/server protocol, look here: https://ccvs.cvshome.org/source/browse/ccvs/doc/cvsclient.texi You should be able to find a doc/cvsclient.info file and a doc/cvsclient.ps -- these forms of the document describe both the pserver framework and protocol (as well as the kserver and server protocols). If you plan to read the document closely and you actually care about security, issue ear-plugs to your neighbors so that your screams will not distrub them too much. OK, thanks ;) You are welcome. In general, my personal opinion is that the pserver and kserver protocols should be removed from the cvs sources completely. It is never secure to run the cvs executable as root which is required to use the pserver protocol. The cvs sources were never designed with security in mind and running them as root is idiocy. (Just say no.) You're kidding right? Root is a good user(TM), no? Actually, no, I am not kidding. Root has too much power to run an untrusted application that has been in the past and likely will be again in the future subverted into letting an external agent execute undesired operations as root on the server machine. If you look at the main page (https://www.cvshome.org/) you will see that even cvshome.org was subject to an attack on a cvs security violation. If cvs runs as root and allows connections on port 2401, then it had better be very well audited and have a very tighly written security model for dealing with all of its inputs and avoid all possibility of a privilege escallation that results in abuses to that connection. There is too much #ifdef'd code and hard to semantically verify code in the current pserver code path for any sane security expert to give anything better than an 'unsecure' rating to it. One way to deal with this problem would be to do something like OpenSSH does with priviledge separation, so that only a tiny fraction of well tested and closely examined code will ever run as root and that it carefully performs its authentication checks and validations. Further, it would not provide for a password that is only obscured on the wire, but is otherwise transmitted in the clear for use in any kind of replay attack you wish to imagine. The only time it might make sense to have a pserver server running would be in a read-only mirror replica of an existing repository on a machine that may be re-installed on a moments notice WHEN (not if) it is found to have been compromised. If said read-only mirror was providing 'anonymous' checkouts, then that might be a useful case for pserver mode to exist (I would still rather see anonymous ssh transport for such purposes.) If you are using pserver, I hope it is on an isolated LAN with lots of firewalls and does not control any sources you really need to be kept secure. I also hope that you are making plans to transition away from pserver usage as fast as possible. I use it since a couple of years on a LAN that has merely an ADSL router listening, and a linux based firewall blocking... in between the LAN and the server is still an SMC Barricade allowing nothing from the outside to create a network session... Guess this is triple secure... I get a lot of probes, but they don't make it through the server... So that should be cool... That might make it a bit more difficult and the 'bad guys' may go looking for easier pray. Summary: Friends don't let friends deploy cvs pserver configurations... Sure
Re: FAQ-O-Matic pserver protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guus Leeuw jr. [EMAIL PROTECTED] writes: Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on boxes other than Windows.) No, and I won't. I am a long time believer of CVS pure ;) LOL. Okay. :-) (I just hope you didn't hur Arthur Barrett's feelings. :-) I honestly think that the cvsnt stuff has its place in the scheme of things. I just wish they didn't have so many different authentication methods... I am enough of a realist to know that there will be many different clients out there as well as more than one server implementation. I think of this as mostly being healthy. I am also looking with interest to see what the OpenBSD folks do with their OpenCVS implementation of cvs. I'd assume most people out there use the CVS 1.11 branch of things, so I'd stick passwd in the feature release for the hard-edge to test, and then maybe a back-port? Well, it is hoped that sometime this year 1.12.x will become the STABLE release and 1.11.x would become deprecated. We have been resisting putting anything but bug fixes into 1.11.x and a new option like 'cvs password' would not fit the criteria for an official backport. If you wanted to provide a patch that folks applied to older releases, you could that. Well, if I'd do it, I'd do it because of: 1) It seems useful (Jim suggested such) Yup, I am sure there are a number of folks who believe it to be useful. 2) Larry, Derek, and you Mark would want it in the general CVS... I can not speak for either Larry or Derek. That said, if you really are planning to cleanup pserver to make it 'secure' for changing a password, maybe you can find the time to do a more secure replacement code base for the pserver implementation instead? If you can get security folks to go thru all possible code paths and shake out the next big bug (and fix it), then I am sure a lot of folks would appreciate your work. Maybe... We'll see. Let me first tackle the password stuff, and later, I might have time to go about pserver in general... Fair enough. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCEAKD3x41pRYZE/gRAgzPAKDaWItMA9nI0C9/F8gSM4uYg1h6dQCfZ8hr veweDg8v8dR7oUTqKUb/xOc= =uMBV -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can't specify username with cvs-rsh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Babcock [EMAIL PROTECTED] writes: On a shared webhost, my username is [EMAIL PROTECTED] and the hostname is jimrandomh.org. With ssh, I can log in fine with ssh -l '[EMAIL PROTECTED]' jimrandomh.org. However, I can't find a way to get CVS to pass the correct options. If I use export CVS_RSH=ssh cvs -d :ext:[EMAIL PROTECTED]@jimrandomh.org:/cvs init Then it misparses this as user:jbabcock, host:[EMAIL PROTECTED] If I use export [EMAIL PROTECTED] cvs -d :ext:jimrandomh.org:/cvs init then it just ignores the USER environment variable. There doesn't seem to be any option to specify the username separately (like ssh's -l). So, how do I use CVS if my username contains an @ character? Add the following two lines to your $HOME/.ssh/config file: Host jimrandomh.org User [EMAIL PROTECTED] Now you should be able to use export CVS_RSH=ssh cvs -d :ext:jimrandomh.org:/cvs init with no problems. The ssh executable itself will send the correct identification for you. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCBRwd3x41pRYZE/gRAuEIAKCjCbd9HvWZOJhzpzn26+vM96jI0wCffHe9 cCFiuyNjYc0XD0NwSzt8wkg= =p1Pm -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff and unknown files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg A. Woods [EMAIL PROTECTED] writes: Yes -- we are in almost full agreement, but it cannot use '-n'. (no commitinfo scripts are run with '-n' and I don't think they should be or ever need to be) I believe this statement does not reflect the current state of cvs. (I may have missed something where you wanted to change the existing behavior and are using that as the basis for your statement.) The commitinfo triggers are run even when the -n switch is used. Try it for yourself with a stock version of cvs 1.11.x or cvs 1.12.x. cvs -d `uname -n`:/tmp/my-repos init cvs -d `uname -n`:/tmp/my-repos co CVSROOT cd CVSROOT echo 'DEFAULT echo commitinfo trigger running:' commitinfo cvs commit -m new-default commitinfo touch foo cvs add foo cvs -n ci -madd-foo foo You should get the output: commitinfo trigger running: /tmp/my-repos/CVSROOT foo In addition, the current 'cvs' requires that you actually contact the server to cause a new directory to be added. If I just do a simulated call that modifies a 'mkdir newdir cvs add newdir' to these steps: mkdir newdir newdir/CVS echo 'D/newdir' CVS/Entries cp CVS/Root newdir/CVS/Root echo `cat CVS/Repository`/newdir newdir/CVS/Repository touch newdir/CVS/Entries then subsequent 'cvs update' operations will have problems such as this: % cvs up cvs update: Updating . A foo cvs update: Updating newdir cvs update: cannot open directory /tmp/my-repos/CVSROOT/newdir: No such file or directory cvs update: skipping directory newdir % which will require that 'newdir' be created via a 'cvs add' conversation with the server eventually. As a reminder, no matter how much folks believe things should be different: - currently the 'cvs add' command talks to the server - on the occasion of a 'directory' being added, the directory is created in the repository if a lock may be created and valid permissions exist to create it. Next, the loginfo trigger is run. Any changes to cvs to alter the behavior of 'cvs add' should allow for new clients to talk to old servers and for old clients to talk to new servers in addition to new clients talking with new servers. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCAWNI3x41pRYZE/gRAgcDAJ9PFZp5BsFd+DbwyZb9sggYIn/ltgCgtbRn 0cXV85BlYqwfwNaPd3dbF1Y= =RieR -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: user privileges for files / dirs / modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: Is it possible to give specific files / directories / modules specific user privileges? We need to be able to give people access priviledges to selective directories. Normally, one has access only to the component that he is working on. Look at cvs_acls as a part of your commitinfo trigger. Documentation here: https://ccvs.cvshome.org/nonav/source/browse/*checkout*/ccvs/contrib/cvs_acls.html?rev=HEADcontent-type=text/html Source here: https://ccvs.cvshome.org/unbranded-source/browse/*checkout*/ccvs/contrib/cvs_acls.in?rev=HEAD -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB/+Eu3x41pRYZE/gRApycAJ4tYwtBQ1aGvNr2KLWfohzWfNjXUwCeMUuI wqRqDflyS0+mDNduZJWt1+I= =PhLK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Overview of files / dirs / modules in the repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: Is it possible to get some kind of overview of the CVS repository structure without using 3rd party tools like viewcvs? cvs checkout -d -l top . I'm asking because if for example a user forgets the module he checked in two weeks ago. How does he find out the name of the module? cvs checkout -d top . -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB//FM3x41pRYZE/gRAsf7AJ9z4suSq1IzWdJqrnSWmYNJESnMeQCfef2A 97H/5lO36lq9BBDRqMX6/iw= =+svO -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with cvs_acls script?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Captain Tantric [EMAIL PROTECTED] writes: This could be something I've done wrong, but am at a loss as to figure out a way around it. I'm running cvs 1.12.11 on Linux and have recently added the cvs_acls script to my commitinfo file. The cvs_acls script works properly, the problem appears to be the way it is invoked by the line in my commitinfo, which is entered as described in the documentation for cvs_acls. ALL $CVSROOT/CVSROOT/cvs_acls -u $USER -f /var/log/cvscommit.restricted When I attempt to commit a restricted file, I get stopped by the cvs_acls script, but I also get the following warning... [EMAIL PROTECTED] CVSROOT]$ cvs commit -m Test commit modules cvs commit: warning: commitinfo line contains no format strings: /cvsroot/CVSROOT/cvs_acls -u dmills -f /var/log/cvscommit.restricted Appending defaults ( %r/%p %s), but please be aware that this usage is deprecated. Access denied: Insufficient authority for user: 'dmills' to commit to 'CVSROOT'. Contact the CVS Administrator if you think you require update access to these directories or files. File(s)/dir(s) restricted were: CVSROOT/modules cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! While not fatal, they are distracting and I'd like to get rid of them if at all possible. Simply adding the parameters it speaks of does not work and in fact breaks the cvs_acls script. Any and all suggestions welcome, TIA! You may find doing something that enables the use of the new format strings to be desirable... cvs checkout CVSROOT echo 'UseNewInfoFmtStrings=yes' CVSROOT/config cvs commit CVSROOT/config -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCABDH3x41pRYZE/gRAut/AJ4+7ruX/YrME2AQ1RWKHFugcTKdVgCguifn ZVZFSVhpCgmXx9TTFVQoAhs= =x9Mk -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs add' client/server semantics (was Re: Triggers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: On Jan 30, 2005, at 10:24 PM, [EMAIL PROTECTED] wrote: At present, it is clear from both sides that the 'cvs add' behavior is broken. I have probably missed some of the points, but let me try to summarize: - a new directory that is added with 'cvs add' does not go thru any peremptory enforcement checks at all (a cvs add trigger OR a policy that cvs add is a local-only operation would partially fix this provided that some other trigger addressed the creation of a new directory in the repository). I'm not sure I fully understand what was said in this paragraph, but I'd like to say that I believe that adding directories should also be triggerable events, and that policies enforcing directory additions could be potentially different from policies enforcing file additions. Expanding on Mark's example, a second policy might require that directory names can not contain period (.) characters. To make this happen, the trigger must be aware of the kind of artifact that's being added. At present, a 'cvs add' will create a new directory and the 'loginfo' trigger will be run with the new directory name given to the script. So, the cvs administrator has no option to fail the 'cvs add' operation before the new directory is already part of the repository. That is to say, that 'cvs add' does have a trigger it uses, just that it is not useful to a preemptive action. - related to this, the 'cvs import' functionality is likewise 'broken' as it currently may stomp on existing tags and could create files and directories that are not acceptable to an administrators policies. There are presently no enforcer triggers that prevent a particular user from doing an import into the repository. This is true, and integrating triggers into import requires a lot of thought. I would suggest as a topic of discussion that import should scan the input tree and run all triggers in advance of the first change of persistent state. But this is a very touchy subject because the vendors that make the drops may in fact make changes to the tree that violate local policy. The CVS admin is then faced with a dilemma: Should the tree be imported as-is for accurate tracking of vendor drops, or should the tree be adjusted according to local policy and potentially breaking the vendor drop? That would seem to want to be a knob in the CVSROOT/config file for setting policy. However, at the least, I'd suggest that passing the names of the tags to be used for the vendor and version to the 'taginfo' trigger is probably desirable to try to stop folks from stomping on an important tagname that might already exist in a previously imported revision. - there are good reasons for both 'cvs add' and 'cvs rm' to be considered as local operations that should not contact the server: a) allows read-only users to generate 'cvs diff -N' output to send to a maintainer I think this is common only when the user has read-only access to the repository, correct? Yes. Or, when a user is using a 'guest' account for read-only mirror rather than the read-write accout she may be entitled to use with the primary repository that may be hidden behind a firewall of some kind. b) lets the local user experiment with re-oranization of the hierarchy of a module. (It is unclear if there would be any easy way to 'rename' files in the local tree and resolve them in a reasonble manner with the cvs server at a later date.) Depends on what you mean by resolve. After mv'ing a directory in a workspace to something new, CVS still maps it to its original location in the repository. If you're thinking about somehow having the rename be reflected in the repository, then you're treading dangerously close to another heated argument. :-) If I move 'foo.c' to 'bar.c' the CVS/Entries file is going to be confused. In general, doing lots of bulk renaming and local 'cvs add' and 'cvs rm' operations without contacting the repository could be useful in some situations, but could be very confusing as well. I was trying to outline what I thought I read as reasons behind the desire that 'cvs add' and 'cvs rm' operations should all be local. It is possible that I have misrepresented them. c) allows a user to continue to do useful work even when access to the server is unavailable (it might be down for maintenance, or the user may be working from a disconnected network). Yes, this is an issue. - there are good reasons for 'cvs add' to have an advisory process (which becomes an enforcement at cvs commit time) a) inform the user early that a proposed addition will fail at such a time that the user does a 'cvs commit' so as to minimize the amount of work that is done under a mistaken assumption
Re: How to use cvs with a group of users and restrictive file perms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver Lehmann [EMAIL PROTECTED] writes: I would like to use cvs with a group of users. That fact alone is quiet easy to handle by doing what https://ccvs.cvshome.org/fom/cache/92.html says. The problem I have is, that the files I want to manage with cvs are having restrictive permissions like 0700 and so on. cvs adjusts those permissions and when I checkout the files I get 0755 for example (like the directory has where thoses files are stored in - group-setuid mode). That is really bad is there a way to tell cvs that I want my files with a special mode checked out? Or do you see any other ways of how to handle this? If you are using a UNIX or Linux client, you should be able to use: umask 077 cvs checkout module and have all of the files and directories checked out by cvs be of the mode you seem to want. If for some reason umask 077 is not possible, the addition of a command like: cvs update module chmod -R go= . would change the files and directories to have permissions you want. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB/l7k3x41pRYZE/gRAjykAJ47FiHp9zXoXrzNy3w7NPNElW2vSQCePdLW Iq8VReFTdqupR+JmkPkyjtk= =wyGF -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to use cvs with a group of users and restrictive file perms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver Lehmann [EMAIL PROTECTED] writes: If you are using a UNIX or Linux client, you should be able to use: umask 077 cvs checkout module The problem is, that it isn't generious 0700 some files are having other modes and so on... (each as restrictive as possible in that environment) If you do not want write mode, then use umask 077 cvs -r checkout module This means that the only files that will have execute bits will be those that have them in the repository. Files will be read-only and directories will be rwx mode. In all cases, there will be no 'group' or 'other' permissions on the files and directories you have checked out of the repository. Your initial problem statement seemed to indicate that this was all you needed. If you need something else, you need to give examples of what fails to be satisfied by this method. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB/mnZ3x41pRYZE/gRAtsfAJ41oF5B4EEQeX2epYUE6aUsNGRYYwCgy2ss lZwAswy8bhjJTVywKcRW/B8= =0Z7A -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: 'cvs add' client/server semantics (was Re: Triggers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: Wait a second. The OK for addition, but wrong for commit is exactly the status quo. The cvs add command succeeds, cvs commit fails due to commitinfo. What I'm proposing is bad for addition, bad for commit, where cvs add fails on those occasions when we know at that moment that cvs commit will also fail. That's not to say that we will *always* know at add time that the commit will fail; failures can occur due to problems in their content which are clearly not ready to check at add time. I find that concrete examples are useful... Does this one illustrate the usefulness your suggested change? Consider a shop which has a majority of folks using either UNIX or Windows clients as their primary development base. A file exists the mymodule/directory called 'MyFoo.h,v' and the local policy is that once a file has been added to the repository, no new file that a difference only in the case of the filename may be committed to that directory should be different only in case. So, the addition of a file named 'myfoo.h' to the directory should be allowed. The commitinfo will make this check as a part of the policy. If there were triggers for 'cvs add', then those triggers could notify the user that adding 'myfoo.h' conflicts with the existing 'MyFoo.h' which would possibly stop a lot of modifications that '#include myfoo.h' from doing the wrong thing that would otherwise only be caught by the 'cvs commit' triggers later. In this case, a UNIX user may have forgotten that when a windows user checks out 'MyFoo.h' there is no room for a new 'myfoo.h' to exist in the same directory. It is also possible that the 'policy' being enforced would be that no mixed-case .h files should live in such a directory, so that only 'myfoo.h' would be allowed to be added in the first place. Now, I will grant that it is certainly possible for a user to 'fix' their checked out tree to work around this problem. However, it may be desirable to get it right the first time rather than waste time later. However, I am not sure how this argument for an advisory trigger at 'cvs add' time which then becomes a manditory 'enforcement trigger' at commit time would not also be potentially very confusing to the users. At present, it is clear from both sides that the 'cvs add' behavior is broken. I have probably missed some of the points, but let me try to summarize: - a new directory that is added with 'cvs add' does not go thru any peremptory enforcement checks at all (a cvs add trigger OR a policy that cvs add is a local-only operation would partially fix this provided that some other trigger addressed the creation of a new directory in the repository). - related to this, the 'cvs import' functionality is likewise 'broken' as it currently may stomp on existing tags and could create files and directories that are not acceptable to an administrators policies. There are presently no enforcer triggers that prevent a particular user from doing an import into the repository. - there are good reasons for both 'cvs add' and 'cvs rm' to be considered as local operations that should not contact the server: a) allows read-only users to generate 'cvs diff -N' output to send to a maintainer b) lets the local user experiment with re-oranization of the hierarchy of a module. (It is unclear if there would be any easy way to 'rename' files in the local tree and resolve them in a reasonble manner with the cvs server at a later date.) c) allows a user to continue to do useful work even when access to the server is unavailable (it might be down for maintenance, or the user may be working from a disconnected network). - there are good reasons for 'cvs add' to have an advisory process (which becomes an enforcement at cvs commit time) a) inform the user early that a proposed addition will fail at such a time that the user does a 'cvs commit' so as to minimize the amount of work that is done under a mistaken assumption that the commit would succeed. b) provide for a simpler kind of trigger implementation to just implement policy on newly created files at commit time. c) the addition of pre-event and post-event triggers to cvs commands that presently modify the repository allows more control for a cvs administrator to enforce policy pro-actively. If the 'cvs add' commands continues to allow modification of the repository (creation of new directories), then there needs to be a way to catch abuses of policy. So, it comes down to a choice of how should the 'cvs add' command operate going forward and where is the correct place to add 'enforcer' triggers for the administration of a repository. I am finding Paul's arguments for additional flexibility for the
Re: CVS diff and unknown files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Greg, Greg A. Woods [EMAIL PROTECTED] writes: [ On , January 21, 2005 at 20:06:37 (+0300), [EMAIL PROTECTED] wrote: ] Subject: CVS diff and unknown files. Is there a way to include contents of unknown files into the 'cvs diff' output? I did try the -N switch but it doesn't seem to do the trick. You must cvs add the files before they can be seen as new. I can't 'cvs add' the files as the repository is read-only for me (public read-only repository of an open-source project). Yes, you can, or at least you should be able to. cvs add does not (and must not :-) contact the server. When I use mkdir foo cvs add foo it contacts the server and creates the directory on the remote reposiotry using either the current stable or feature releases of CVS. In addition, I believe you will find that a 'cvs add' for a normal file will also contact the server in order to create a CVS/Entries entry for the new file with a '0' version and a 'dummy timestamp' as well. While it has been proposed that this behavior should be changed, no change to this behavior has been committed to the CVS sources as yet. So, even if it 'must not' exhibit this behavior, it does appear to exhibit it at present. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB8xMV3x41pRYZE/gRApXyAJ0b1C6NFGM/XEGtZ8phZMGlwYqCFwCgpPR+ yD54uze0jmtHqDuyf0AfYu0= =q+NZ -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT: No such file or directory?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: I hate google groups. Had a whole thing typed out and ready to send and it failed, erasing all I had. Here's the skinny: SETUP: WinCVS 1.3.20.2 Beta 20 (Build 2) with CVSNT running on Windows 2000 CVS 1.11.5 running on Solaris 8 2/04 s28s_hw4wos_05a SPARC CVSROOT directory exists on server and is checked out to local dir. CVSROOT system environment variable exists on local machine and on server. PROBLEM: Cannot 'cvs release' any modules from my machine with WinCVS back to cvs repository on server using the command 'cvs release -d -f module_name'. Produces error message 'cvs [release aborted]: /usr1/webroot/cvs/repository/CVSROOT: No such file or directory' First, the 'cvs release' command accepts a list of directories relative to the current directory, not a module_name. Second, I have seen something similar related to NFS operations on some hosts where the directory being released was on an NFS mounted directory and there were kernel messages like 'got bad cookie vp hexstring bp hexstring' with the user seeing something like: % cvs release -d foo You have [0] altered files in this repository. Are you sure you want to release (and delete) directory `foo': yes cvs release: deletion of directory src failed: Directory not empty % but I have not actually seen the error you are reporting. (Note: In the above case, the problem was apparently related to http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57696 which was a FreeBSD NFS client issue.) -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB7qhc3x41pRYZE/gRAkcUAJ9oi4vI8X5bKBoEb0TsaEvUgj+gqgCfT2c1 wjtLTbjymKgFKaexSRRIJ38= =Pp5K -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS w/ ssh - chroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grand Poohbah [EMAIL PROTECTED] writes: I am setting up a FreeBSD 5.x machine with cvs 1.11.17. My goal is to have a guest style read-only access to a cvs repository under a strict chroot environment. I have setup my repository with file permissions similar to those found in the how-to http://www.idealx.org/doc/chrooted-ssh-cvs-server.en.html However, instead of using a rssh or a smrsh type of shell, I am attempting to do a classic chroot. The cvs user logs into the server with ssh and get dropped into a chroot directory. I have place what I believe to be all the necessary files (cvs binary, permission/group files and repository files) for cvs to work inside this chroot environment and it *seems* to be working as intended as a chroot environment. However, when my remote system attempts a cvs update -Ad (or diff or other client command) I get the following errors. Root: not found Valid-responses: not found valid-requests: not found Then the process just hangs until a ^C Question: is there a debug or verbose mode I can use to get more output? I have the mirrored repository file structure and permissions set up correctly, my only binaries I have are the following /bin/sh /bin/chroot.sh /bin/ls /dev/null /usr/bin/rsync /usr/bin/cvs You will likely also need some libraries. A stock version of FreeBSD comes with a patched version of cvs 1.11.5-FreeBSD and needs a number of libraries: % uname -a FreeBSD test52 5.2-RELEASE FreeBSD 5.2-RELEASE #0: Sun Jan 11 04:21:45 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 % /usr/bin/cvs -v Concurrent Versions System (CVS) 1.11.5-FreeBSD (client/server) Copyright (c) 1989-2002 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS % ldd /usr/bin/cvs /usr/bin/cvs: libgnuregex.so.2 = /usr/lib/libgnuregex.so.2 (0x280f3000) libmd.so.2 = /lib/libmd.so.2 (0x280fb000) libcrypt.so.2 = /lib/libcrypt.so.2 (0x28105000) libz.so.2 = /lib/libz.so.2 (0x2811e000) libgssapi.so.7 = /usr/lib/libgssapi.so.7 (0x2812c000) libkrb5.so.7 = /usr/lib/libkrb5.so.7 (0x2813a000) libasn1.so.7 = /usr/lib/libasn1.so.7 (0x28177000) libcrypto.so.3 = /lib/libcrypto.so.3 (0x2819d000) libroken.so.7 = /usr/lib/libroken.so.7 (0x282ab000) libcom_err.so.2 = /usr/lib/libcom_err.so.2 (0x282ba000) libc.so.5 = /lib/libc.so.5 (0x282bc000) % Your cvs might be more static, but you should look closely to be sure. Does cvs server need more binaries to work properly? Is there a way I can run cvs server by hand from the chroot environment to simulate what my client should be doing? Look at what 'cvs -t' does (for cvs 1.12.x you may use up to three '-t' options at once). Look at what the environment variable CVS_CLIENT_LOG provides (when given a prefix pathname it will create a .in and a .out that contains the conversation that occurs across the client/server connection). Read the doc/cvsclient.text file (or one of the generated output formats of it) to better understand the client/server protocol being used. At a guess, your cvs is not properly getting the 'server' argument right now somehow. If the client is using cvs -t :ext:host.dom.ain/path/to/repository then you should end up seing something like this output $CVS_RSH host.dom.ain $CVS_SERVER server where the values of $CVS_RSH may be replaced with 'ssh' or 'rsh' and $CVS_SERVER is probably replaced with 'cvs' Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB6Bnd3x41pRYZE/gRAtwfAKCkxbZ9Wy81qw9j8hGbCqEOz8M/tACfaFs4 V+ayvTbqvwqZDG8+tkLLB8U= =goUj -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: .cvsignore *.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Bornhaupt [EMAIL PROTECTED] writes: Hi Jim, i want to use *. in the .cvsignore file But it does not work. Is there a workaround? Ignore the parent directory. Ignore the parent directory is *.* and this would work. I want to ignore *. my C-Compiler creates binary files without extension. But this files are not nessesary in the CVS regards Thomas Given a file 'foo.c', is your compiler creating file 'foo' or file 'foo.' ? The *. pattern requires the dot be a part of the filename (at least on UNIX and the cvshome.org version of CVS). If you wanted to ignore the file 'foo' you would probably need to use [-_a-zA-Z0-9]* as the pattern to ignore. You should specify the OS, the version of cvs, and an explict example of what file or files you are trying to ignore if this is not the case. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB4/R33x41pRYZE/gRAsoYAJ9VxxFQwctSxmfTzKJGJJ3c+vFxeACgtoAl bTwiBJiT9TM6G40j7lvPvUE= =SysF -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [Fwd: Q on keyword substitution]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jsWalter [EMAIL PROTECTED] writes: Is there a way to have a substitution happen only once? ie: I'm using phpDocumentor and would like to have the '@since' tag auto insert the CVS file version, but not change it the next time the file is submitted. this... * @since $Version: $ to become... * @since 1.24 not... * @since $Version: 1.24$ So, I'm asking for a one time substitution. And, yes, I could modifiy the line enext time I'm in the file, if I remember. Any ideas? 'cvs admin -ko' after the first commit. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB3Ojf3x41pRYZE/gRAoRGAJ46RU7F639sjZyUHfkk3+gp9Ne8SgCg0DC6 jTFfIhDCPhreZfTyXxupaY4= =Ibyd -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: ## Need help to configure CVS ##
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: 2. Tell me what is YOYO. Is there is any special meaning for that? There is no 'YOYO' in cvs to the best of my understanding. More context is required if you want to track it down. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB1AtH3x41pRYZE/gRAgi2AKCU0hug/f8i6nbW71z8nyXOOSjr3gCeIKdq YVgH+rjPILVjIcLENsVJuk0= =ZwLK -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Checkout problem after upgrading from 1.12.9 to 1.12.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Astarna [EMAIL PROTECTED] writes: Thanks for responding... no.. not a whisper on this problem. Very frustrating. I too downgraded to solve the problem. I'm surprised others aren't experiencing this problem. not everyone is uinsg cvs 1.12.x releases as yet. i have not tried using eclipse clients with 1.12.11 yet, if you can provide a step-by-step bug report to bug-cvs@gnu.org it would be helpful. It is possible that it is an eclipse problem too... -- Mark hanji On Tue, 28 Dec 2004 13:12:33 +0100 Marco Leone [EMAIL PROTECTED] wrote: Hi, I've ecountered the same problem: Internal error, resource does not start with root with CVS 1.12.11 and Eclipse clients. At the moment I downgraded to version 1.12.9 to let Eclipse's users checkout projects. Did you receive any answer regarding your mail to the info-cvs list? Best regards. -- Marco Leone ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB00Id3x41pRYZE/gRAoiSAJ0ed5aiCfa+nYjf/HXZSHqg/rfGBQCfbu9a l/82e6APCCaOiDCwRBeqRRM= =dYK3 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is it safe (for repo) to downgrade server from 1.12.xx to 1.11.xx?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Sampaleanu [EMAIL PROTECTED] writes: I am currently running 1.12.11, but have a problem in that my main IDE (Eclipse) can not handle the dates put out by it, so in the revision history in Eclipse I have no date display, which is extremely annoying. Sounds like you need to file a but with eclipse folks to parse iso 8601 dates properly... it should not be that hard to fix. One possible solution is to downgrade from 1.12.11 to the last version in the stable branch, 1.11.18, but I am assuming that this may not be safe for my existing repo produced by the feature branch. Is this the case, or am I safe to downgrade? A downgrade is still safe. You may need to adjust your commit scripts and your CVSROOT/config file depending on if you have adopted any of the newer features, but the reporitory RCS files are still the same and the protocol is still the same. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB00Mz3x41pRYZE/gRAmp/AJ9rHPaq6q8R3NrKdGHwELZENMcJ6ACgi5ij SzUFGckhbkPMSOkPLiH0rcM= =oD5g -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server $HOME (was Re: (no subject))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gunnar Ahlberg [EMAIL PROTECTED] writes: I'm using ssh for connection using export CVS_RSH=ssh and cvs -d:ext:developer@server:/repository Of course, on the CLIENT HOME, the .ssh file is needed. True, especially if the client machine is going to use publickey authentication or needs special $HOME/.ssh/config configurations. If the server side does not have any $HOME/.ssh/authorized_keys file, then publickey authentication is not viable and it may be that the client will no need a $HOME/.ssh directory for anything other than the random seed and possibly a config file. What I was wondering about is what the users HOME on the SERVER is used. $HOME/.ssh/authorized_keys is typical. Depending on how your sshd_config file is setup. sshd wants the $HOME/.ssh directory owned by the user doing the connection and with no group or other write permissions. The same is true of all files leading to the root of the filesystem for $HOME. Nothing, I presume? That is a bad assumption. I had a problem with the cvs client in Eclipse. For some reason, it needs the SERVER HOME for some reason I'm not going to ask you guys since it's all Eclipse specific. Oh well, thank you! Enjoy! -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFByEOD3x41pRYZE/gRAuJiAKC4mqabzXKNYnNrG4WYZiKHqlRtpACfZeXU wSvUCAlSk3hpFlhAlIk4EKk= =oJ3C -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: OT - store only the latest version of some files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kamaraju Kusumanchi [EMAIL PROTECTED] writes: I am wondering if cvs has capability to do this. If not please tell me what the right tool is. You probably do not want to use a source control system for this. Just copy the results of a 'build' to a known good 'golden' directory along with the SHA fingerprints of the files used to generate it. We are using debian sid. I have a project which we need to maintain the source code by a version control system. The project also deals with some data files (around 20 or so text files each 100MB). Data files are typically not source. So, you probably want to investigate configuration management systems that may exist with features that you want... The data files can be substantially different between succesive versions. So we do not want to store the data file as diffs (as it consumes a lot of space). Moreover, The data files can be generated once you the source code is available. But generating the data files takes up a long time. So, you are really talking about an optimization step to get the generated data file out of a cache that has reasonable fingerprints on the input files used to generate the file. So the solution we came up with is to store only the latest version of the data files and remove any older versions. I am wondering if cvs is capable of doing this namely to store the source code with version control and to store only the latest version of the data files? Not really. I suppose you could use 'cvs admin -ox.y' to cause version x.y to be deleted from the CVS repository if there were great need. It does not sound like you have that great a need to store these files under CVS to me. We are not particular on using cvs for version control. So if there is other version control program capable of achieving the above, we will be glad to shift. Clearcase 'winking' may be a way to accomplish this for you. However, clearcase is a propietary SCM system that has non-trivial cost and learning curve. I have no idea (nor any desire to find out) if clearcase works on GNU/Linux platforms these days. I mention it only to show you additional search terms to look at when trying to find your solution. I think you want to do a search for configuration management software rather than source control management software for your purposes. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBxfKR3x41pRYZE/gRAl7MAJsGfNeG4johhqKSoPwEeYvaQoIOLACgys// b1ZHddPNulXGnr9QtFUZlSI= =uo0c -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Update and removing non-versioned workspace files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Chong [EMAIL PROTECTED] writes:
Is there a way to use update and have any non-versioned files deleted from
your local workspace? -C doesn't appear to do it.
I have been known to use the script below when I was still playing
with .cvsignore and Makefile files and needed to have a pristine copy of
the files that were cvs controlled in my directory... it was a quick and dirty
hack.
Use it like this:
~/non-cvs.perl |xargs /bin/rm -fr
but it is probably better to look at the output before running it thru
xargs to nuke everything.
-- Mark
: # use perl
eval 'exec perl -S $0 ${1+$@}'
if 0;
# find all non-cvs controlled files
use strict;
use File::Find;
my(%globalfind, $key);
File::Find::find(\wanted, '.');
foreach $key (sort keys %globalfind) {
print $key,\n if ($globalfind{$key} ne 'cvs');
}
sub wanted {
my($name) = $File::Find::name;
my($dir) = $File::Find::dir;
if ($_ eq 'CVS') {
$File::Find::prune = 1;
$globalfind{$dir} = 'cvs';
proc_cvs_entries($dir, 'CVS/Entries') if ( -f 'CVS/Entries' );
} else {
# not a CVS controlled entity
$globalfind{$name} = 'non-cvs' if ($globalfind{$name} ne 'cvs');
}
}
# Process a CVS/Entries file
sub proc_cvs_entries {
my($pdir, $entries) = @_;
my($entry, $file, $rest);
# A typica CVS/Entries file looks like this:
# D
#or
# D/directory-name
#or
# optionaltag/file/...
if (open(ENTRIES, $entries)) {
while($entry=ENTRIES) {
chomp($entry);
# Just 'D' on a line by itself indicates that all
# subdirectories have been enumerated in the Entries file
# already.
next if ($entry eq 'D');
# We don't care about anything but the name of the file
(undef, $file, $rest) = split(/\//, $entry, 3);
$globalfind{$pdir.'/'.$file} = 'cvs'; # mark as processed
}
close(ENTRIES);
} else {
warn Unable to read $entries: $!;
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFBw7cF3x41pRYZE/gRAuREAJwKYk6vV6DlpP4omcpNxDfDRhDWogCgof+4
hK9hOH8Ac0Ur3qPZpwbaTlM=
=p3cP
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: possibly bug using cvs release with multiple repositories
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Martin,
It sounds like this is probably a bug in cvs. You may wish to open an
issue on the cvshome.org site about this so it does not get lost and
post the URL to the [EMAIL PROTECTED] list.
-- Mark
maronie [EMAIL PROTECTED] writes:
I ran into the following problem using cvs 1.11.18 (same with 1.11.5)
locally as well as in pserver mode:
I have two repositories /cvs/repo1 and /cvs/repo2
with the directories
/cvs/repo1/mymodule
and
/cvs/repo2/mymodule/doc
resp.
When I do
cd ${HOME}/sandboxes
cvs -d /cvs/repo1 co mymodule
cd mymodule
cvs -d /cvs/repo2 co -d doc mymodule/doc
everything works fine for the moment.
I can use cvs update/diff/commit/log/status without problems.
But when I try to use cvs release:
cd ${HOME}/sandboxes
cvs release -d mymodule
then I get the error messages:
cvs update: cannot open directory /cvs/repo1/mymodule/doc: No such file or
directory
cvs update: skipping directory doc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `mymodule': y
cvs release: no such directory: mymodule
Of course there is no directory mymodule/doc in /cvs/repo1, it should
be searched in /cvs/repo2.
But even much worse:
If I have modified some file in directory doc (say
mymodule/doc/myfile.doc) the messages are identical (even You have
[0] altered files in this repository. !!!). So cvs obviously doesn't
recognize the modifications I made to myfile.doc and my work is lost
without warning.
Is this really a bug or did I miss something?
(BTW we chose to use a separate repository for the docs as we are
unfortunately stuck to M$ Word documents for historical reasons - and
you all know about the problems with binary files in cvs.)
Cheers,
Martin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFBvyS63x41pRYZE/gRAlToAKCua6ZaqFqMWhtcp2a5OHaphcaFNACg0WFc
d5UInxFxjny10HYr/BE6LBs=
=wD4g
-END PGP SIGNATURE-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Questions about upgrading the server to the latest CVS version.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Limor Yaakov [EMAIL PROTECTED] writes: Note: You sent this message multiple times to both the bug-cvs and info-cvs lists. You would do better to send a single message to the info-cvs list and wait until folks get to responding. If you don't get a response in a week or so, then resubmit the message asking for help. This is NOT a chat line, please don't abuse it. My name is Limor Yaakov and I am the QA Manager of Smart Link company. We are using CVS as a configuration management tools. The configuration is as follow: 1. Server - CVS server version 1.11.1p1 is installed on Linux server 2. Client - WinCVS version 1.2 (as the adminstrator of this tool I use the latest 1.3 beta version). As I am quite new to CVS, I have some questions regarding upgrading the server to the latest cvs version. As I wrote above, we are using quite an old cvs version 1.11.1p1 while the latest one is version 1.1.18. [1] Is there any implication or warnings that I should be aware of when upgrading from version 1.11.1p1 to 1.1.18 or is it a smooth upgrading without any side effects ? It should be smooth. Read the NEWS file and don't forget to use 'cvs init' to add any missing administration files to your CVSROOT. [2] Should I take precaution before upgrading like creating a backup of the repository ? This is always a good idea even when you are not doing an upgrade. [3] Are there any operations that being done on the repository during the upgrade ? Only the 'cvs' binary needs to be upgraded on the machine. I would probably 'mv cvs cvs- mv cvs.new cvs' and then later when no cvs processes are running remove the old 'cvs-' file, but if no one is actively running a cvs command when you do the update, you are safe just doing a standard 'install' of the new cvs version. [4] What is the preferable version. Is it the STABLE version or the FEATURE version ? I have in the past used FEATURE for my server and STABLE for most of the clients at present, but I am getting to believe that FEATURE is good enough to put into production for both. [5] Are you familiar with any Bug Tracking application that can be easliy integrated with CVS and is also feature-rich ? I have seen both Bugzilla and GNATS integrations with cvs. It is fairly easy to modify the example commit_prep and log_accum scripts in conjunction with a verifymsg script to deal with sending e-mail to any bug tracking system that makes sense. I would really appreciate your help on this issue. Best Regards, Limor. CVS Server is installed on Linux Server and as a client we are using WinCVS It is worth noting that CVSNT is used by default in WinCVS and that there does exist a Linux port of CVSNT if you wanted to make use of a consistent vendor for cvs across all of your platforms. However, the CVSNT client/server discussions do not really happen very much in the [EMAIL PROTECTED] list which has a primary focus of the cvshome.org version of CVS. -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBvyNu3x41pRYZE/gRAjD8AKCNs3lBVjYjmAalkitD2kQVTadrowCeMEUq NcHa0n4pjPv85dhdSWn3oXU= =C3LQ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Feature Version 1.12.11 Released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Connolly [EMAIL PROTECTED] writes: Short of each of us diff'ing the two NEWS files, is there a digest of the new features on the 1.12 branch? You may wish to note that the NEWS files gives the changes since the previous release as a fundamental part of its format. URL: https://ccvs.cvshome.org/files/documents/19/614/NEWS.1.12.11 | Changes since 1.12.10: | ** | | NEW FEATURES | | * Thanks to Conrad Pino [EMAIL PROTECTED], the Windows build works once again. | | * CVSROOT methods and option names are now case insensitive | | * CVSROOT methods :ext: and :fork: now support the CVS_SERVER option. | | * CVSROOT method :ext: now supports the CVS_RSH and Redirect options. | | * Date handling has been improved slightly. | | * Miscellaneous bug fixes. | | * Miscellaneous documentation fixes. | | BUG FIXES | | * Thanks to a report from Chris Bohn [EMAIL PROTECTED], all the source files | needed to build on Windows are now included in the source distribution. | | Changes from 1.12.9 to 1.12.10: | *** ...elided... For more details, you may find the following URL to be useful: https://ccvs.cvshome.org/files/documents/19/613/cvs-1.12.10-1.12.11.diff.bz2 -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBvyrt3x41pRYZE/gRAq78AKDdC6k2AdO8MTo6licFYx2MsRfp6wCfQlWI A+tYfSP4Ck7GGLPQ/x/ewVE= =yHjb -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: backup of a cvs repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] writes: Jennifer Vesperman, author of Essential CVS from O'Reily, has a shell program to lock the repos that you may want to check out. Check in http://www.oreilly.com/. Yeah, http://examples.oreilly.com/cvs/ has the scripts for download. Be advised that the scripts do not really deal with a CVSROOT/config with a 'LockDir=/path/name' option and that they really should be using the full locking semantics with a '#cvs.lock' NOT '#cvslock' directory as is used in the example script. -- Mark -chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of John Sent: Sunday, December 12, 2004 4:40 PM To: [EMAIL PROTECTED] Subject: backup of a cvs repository Hi To do a backup of a CVS repository, we have to lock it. Is it enough to put a #cvs.rfl in $CVSROOT ? Thanks John. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBvc1y3x41pRYZE/gRAqLUAKC5iKAeeeODgo9pU7hxIr9T1HcVTgCg4fEm Ku8dAh4WUJ1aDsiec9opCfY= =Q11S -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
