Re: cvs tag performance

[Rahul]

run "iostat -x 3" or equivalent to monitor the disk for contention.
Look for stats like (see man iostat). On Linux :

   avgqu-sz
 The average queue length of the requests that were issue
 to the device.

await
  The average  time  (in  milliseconds)  for  I/O  requests
  issued to the device to be served. This includes the time
  spent by the requests in queue and the time spent servic-
  ing them.

svctm
   The  average  service  time  (in  milliseconds)  for  I/O
   requests that were issued to the device.


If you see large queue sizes and response times you know you may have a
disk storm being generated when tag command modifies files. Since CVS
doesn't do any concurrent tagging (like mutliple threads or processes
operating on individual dirs etc) you will have to look at faster disk
option.

When you say "it's suddenly taking too much time" there must be other
disk activity kicking in that's causing disk contention when tag
command shows up.


Regards,

===
Rahul Bhargava
CTO, WANdisco
http://www.wandisco.com/cvs

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs tag performance

[Mark D. Baushke]

-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: cvs branch version

[david]

> Hi,
> 
> I used 'cvs tag' to add a file to a branch. I then used 'cvs commit 
> -r... ' to check in a new version. It normally creates a subversion from 
> the version initially tagged. For example, I tag file 'A' version 1.1 
> with "release-patch". It creates a version 1.1.0.2 for the tag. When I 
> check in a new version to the branch, it creates a version 1.1.2.1. But 
> this time, I did not see any output from the command line after I 
> entered the  comments in vi. When I did a 'cvs log', I did not see any 
> subversion created.
>
Did you change the file before committing it?  CVS will not create a new
revision unless there are changes from the old one.
 
> If I do a 'cvs status' on the file, the sticky tag shows :
> Sticky Tag:  release-patche (branch: 1.1.2)
> 
> But I cannot see this revision with 'cvs log'. Can anyone explain what 
> happened?
>
Sure.  You now have the file in your working area as branch 1.1.2, but
since there is no change from the original version, the only revision is
1.1.  This revision is on both the trunk and the branch right now.  That's
what it looks like to me.

David H. Thornley| If you want my opinion, ask.
[EMAIL PROTECTED]   | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs branch version

[Qian Xin]

ypi can use wincvs or other GUI front to help you.
If you are not very familiar with the command line opition, and the
operation.

Enjoy.

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Export

[Larry Jones]

Liquidchild writes:
> 
> When i run the cvs export command either through WinCVS or on the
> command line using
[...]
> it exports the ecc module with the CVSROOT folders and CVS folders.

Have you looked at the repository to see if someone managed to actually
add those directories to it?

-Larry Jones

I've got to start listening to those quiet, nagging doubts. -- Calvin




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Inaccurate documentation re "cvs tag"

[Todd Denniston]

Ming Kin Lai wrote:
> 

> > > Suppose I check out a file with revision 1.1, modify it and
> > > commit it, so now I have revision 1.2 in my working directory.
> >
> >Well this commit does do essentially a checkout (actually update, which is
> >why things like $Log:$ and $Id:$ get updated).
> 
> This makes it clear what you mean by "literally means" - to you, a commit
> essentially does a checkout, so a commit literally means a checkout.  But to
> me, even though a commit essentially does a checkout, it is not a
> "literally" a checkout.  Please note that there is nowhere in cederqvist
> that says a commit is essentially a checkout or a commit implies a checkout,
> etc (if you can find such, please show me).  To an experienced user like
> you, that may be clear.  But as I said, that may be confusing to a new user.
>   A manual such as cederqvist is to make things clear.  People should not
> need a yaer's experience using CVS to understand what cederqvist really
> means.

Ok, unfortunately the way open source documentation works often is "Now that
you understand the problem please describe it in the doc for the next person
and submit the doc patch"

Ok, now that you understand the problem please describe it in the doc for
the next person and submit the doc patch. (on bug-cvs@gnu.org) :)

Honestly, I do find that having someone who does not know, but is trying to
understand, the subject matter DRAG (kicking and screaming) it out of
someone who does, makes some of the best documentation. sorry.


> >If you checked it out there was a check in, which created 1.1.
> 
> Not necessarily.  I initially import the file and then check it out.  There
> is no check-in.  Well, I guess you would say something like "an import
> essentially does a check-in" or "an import literally means a check-in". 

Import is a hack, according to some, that essentially does 
'for i in `find . -type d`; do cvs add $i;cvs commit $i ;done'
'for i in `find . -type f`; do cvs add $i;cvs commit $i ;done'
in an out of sand box tree. I say "essentially" because there are some other
things going on like it puts the initial version on a 'special' branch
(which causes trouble using it with normal branches, and is why some call it
a hack).

> My
> take is that if that's what the CVS designers mean, fine, document it in
> cederqvist to avoid misunderstanding.  A user should be not be left
> wondering whether xxx is essentially doing yyy.

Agreed.
I believe though that much of your (our) confusion came from your use of RCS
keywords, and there are known problems with them.
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_12.html#SEC102
perhaps the updating person should link from annotate documentation to
another "problems with keywords" section in 12.


BTW from section 12.2 Using keywords:
"CVS will automatically (Or, more accurately, as part of the update run that
automatically happens after a commit.) expand the string as part of the
commit operation."
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_12.html#SEC99

Except for users with RCS keywords, the automatic update after commit is
invisible to users. Also IIRC CVS may only do that auto update if the client
found an RCS keyword in the file, but check the code to be sure.


> >In most cases people tag an entire baseline (which is also the better
> >practice), which has a "version", but also has many files which have
> >"revisions". It seems clear as written from here.
> 
> Section 4.2 of the 1.11.20 cederqvist says "To avoid confusion, the word
> version is almost never used in this document."  Apparently the authors of
> the manual think that the use of the word "version" is not clear and may
> create confusion.  And I agree with the authors of the manual.
> 

Some time soon I will attempt to read that and understand it, because I do
see version and revision as two different things. Actually they are similar
but _to me_ apply at different levels and is probably where the confusion
comes in.

quick read... looks like what I mean be version, is release in the documents
nomenclature.
I probably will not remember that though:)


> > > and 1.2.  I think the phase "checked out" should be used with care.
> >
> >It is, you simply have a little learning to do.
> 
> I think everyone, including you, is learning.  I surely hope you can learn
> something from this discussion.
> 
Yes, I need to read subject lines a little closer :)
You just hit my "RCS keywords dont work as I expect" button again today, its
kind of related and kind of bled over.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Inaccurate documentation re "cvs tag"

[Ming Kin Lai]

> Sec 4.5 of 1.11.20 cederqvist says: "running the cvs tag command without
> arguments causes CVS to select the revisions which are checked out in 
the
> current working directory.  ... One potentially aspect of the fact that 
cvs

> tag operates on the repository is that you are tagging the checked-in
> revisions, which may differ from locally modified files ..."
> I think it is somewhat confusing, especially to new users.  At first it
> talks about a checked-out revision, then it talks about a checked-in
> revision. Well, I understand they mean the same, at least in some cases; 
but

> it is not quite accurate and probably confusing.
> 1. The problem with "checked out" is that it does not literally mean
> "checked out".

Actually it does literally mean the version which was checked out, not what
you currently have (i.e., not possible local mods).


Apparently you and I have disagreement about what "literally means" means.


> Suppose I check out a file with revision 1.1, modify it and
> commit it, so now I have revision 1.2 in my working directory.

Well this commit does do essentially a checkout (actually update, which is
why things like $Log:$ and $Id:$ get updated).


This makes it clear what you mean by "literally means" - to you, a commit 
essentially does a checkout, so a commit literally means a checkout.  But to 
me, even though a commit essentially does a checkout, it is not a 
"literally" a checkout.  Please note that there is nowhere in cederqvist 
that says a commit is essentially a checkout or a commit implies a checkout, 
etc (if you can find such, please show me).  To an experienced user like 
you, that may be clear.  But as I said, that may be confusing to a new user. 
 A manual such as cederqvist is to make things clear.  People should not 
need a yaer's experience using CVS to understand what cederqvist really 
means.



> I run "cvs
> tag".  And 1.2 gets tagged.

Because you checked out (updated to) 1.2 by committing it.


Again, I cannot find any place in cederqvist that says when the user commits 
a file, he in effect checks it out.  And that's my point: cederqvist should 
mke this clear or use the word "checked out" with care.



> Literally 1.1 is the revision I checked out.  I
> did not check out 1.2, unless commit implies check out - but I think 
it's

> better separate them; after all ci and co are two different commands.

It was learned long ago that less confusion was created by cvs handling the
immediate update, otherwise cvs would have a hard time being Concurrent
Versions System, the command you imply are serial locking commands and CVS
is a parallel merging system.


I did not imply any command.  What I mean is less confusion would be created 
by explaining what "check out" really mean, e.g. that would be implied by a 
commit.



>  Also,
> stating that a checked-out version is tagged may give the wrong 
impression

> that the user (unnecessarily) needs to do a "cvs co" before tagging.

No the update makes it the checked out version, this is simply a
misconception on your part.


I am pointing out a potential misconception because of the way "checked out" 
is used in cederqvist.


> 2. The problem with "checked in" is that there may not be any check-in 
(cvs
> ci).  Suppose I check out a file for the first time and without 
modifying
> it, run "cvs tag".  The one and only one revision gets tagged; but there 
is

> never any check-in.

If you checked it out there was a check in, which created 1.1.


Not necessarily.  I initially import the file and then check it out.  There 
is no check-in.  Well, I guess you would say something like "an import 
essentially does a check-in" or "an import literally means a check-in".  My 
take is that if that's what the CVS designers mean, fine, document it in 
cederqvist to avoid misunderstanding.  A user should be not be left 
wondering whether xxx is essentially doing yyy.
From this discussion it is quite apparent that you separate the _concept_ of 
checkin and checkout, respectively, from the actual command of "cvs checkin" 
(or "cvs ci") and "cvs checkout" (or "cvs ci"), respectively.  It appears, 
to you, the concept of checkout encompasses both the "cvs checkout" and "cvs 
commit", for example.  I am not arguing about the merit of this way of 
thinking.  Look at the title of my post - "inacurrate documentation".  I am 
talking about the documentation.  If you can find any place in cederqvist 
that explains that the concept of checkin encompasses "cvs checkout" and 
"cvs commit", please show me.  If you do not explain that to a new user, can 
you expect him to somehow figure it out himself?  Yes, he will eventually.  
But why can't the documentation give him an easier time?  cederqvist is not 
just a reference for experienced users, it also serves as a guide for 
first-time users.



> Stating that a checked-in revision is tagged may give
> the wrong impression that the user (unnecessarily) needs to do a "cvs 
ci"

> before tagging.
>

Re: Inaccurate documentation re "cvs tag"

[Todd Denniston]

Ming Kin Lai wrote:
> 
> Sec 4.5 of 1.11.20 cederqvist says: "running the cvs tag command without
> arguments causes CVS to select the revisions which are checked out in the
> current working directory.  ... One potentially aspect of the fact that cvs
> tag operates on the repository is that you are tagging the checked-in
> revisions, which may differ from locally modified files ..."
> I think it is somewhat confusing, especially to new users.  At first it
> talks about a checked-out revision, then it talks about a checked-in
> revision. Well, I understand they mean the same, at least in some cases; but
> it is not quite accurate and probably confusing.
> 1. The problem with "checked out" is that it does not literally mean
> "checked out".  

Actually it does literally mean the version which was checked out, not what
you currently have (i.e., not possible local mods).

> Suppose I check out a file with revision 1.1, modify it and
> commit it, so now I have revision 1.2 in my working directory.  

Well this commit does do essentially a checkout (actually update, which is
why things like $Log:$ and $Id:$ get updated).

> I run "cvs
> tag".  And 1.2 gets tagged.  

Because you checked out (updated to) 1.2 by committing it.

> Literally 1.1 is the revision I checked out.  I
> did not check out 1.2, unless commit implies check out - but I think it's
> better separate them; after all ci and co are two different commands.

It was learned long ago that less confusion was created by cvs handling the
immediate update, otherwise cvs would have a hard time being Concurrent
Versions System, the command you imply are serial locking commands and CVS
is a parallel merging system.

>  Also,
> stating that a checked-out version is tagged may give the wrong impression
> that the user (unnecessarily) needs to do a "cvs co" before tagging.

No the update makes it the checked out version, this is simply a
misconception on your part.

> 2. The problem with "checked in" is that there may not be any check-in (cvs
> ci).  Suppose I check out a file for the first time and without modifying
> it, run "cvs tag".  The one and only one revision gets tagged; but there is
> never any check-in.  

If you checked it out there was a check in, which created 1.1.

> Stating that a checked-in revision is tagged may give
> the wrong impression that the user (unnecessarily) needs to do a "cvs ci"
> before tagging.
> 
> Anyone agrees or disagrees?

Yes, see above.

> 
> Incidentally, the entry for tag in Appendix B (page 132) says "Add a
> symbolic tag to checked out version".  I think "checked out" need to be
> re-worded, and "version" probably should be "revision".

In most cases people tag an entire baseline (which is also the better
practice), which has a "version", but also has many files which have
"revisions". It seems clear as written from here.

> 
> Finally there are a number of places in cederqvist that use the phase
> "checked out".  I am not sure all mean literally "checked out".  For
> example, Sec 1.3.4 says "diff compare[s] the version (revision?) of driver.c
> that you checked out with your working copy."  Again, suppose I check out a
> file with revision 1.1, modify it and commit it, so now I have revision 1.2
> in my working directory.  I run "cvs diff".  There is no difference.  The
> comparison is NOT between 1.1 (the last revision I checked out (using cvs
> co))

see above information about your misunderstanding because cvs commit does an
update to get you synchronized with what is in the baseline after commit.

> and 1.2.  I think the phase "checked out" should be used with care.

It is, you simply have a little learning to do.

> 
> Ming Kin Lai
> 
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Inaccurate documentation re "cvs tag"

[Ming Kin Lai]

Sec 4.5 of 1.11.20 cederqvist says: "running the cvs tag command without 
arguments causes CVS to select the revisions which are checked out in the 
current working directory.  ... One potentially aspect of the fact that cvs 
tag operates on the repository is that you are tagging the checked-in 
revisions, which may differ from locally modified files ..."
I think it is somewhat confusing, especially to new users.  At first it 
talks about a checked-out revision, then it talks about a checked-in 
revision. Well, I understand they mean the same, at least in some cases; but 
it is not quite accurate and probably confusing.
1. The problem with "checked out" is that it does not literally mean 
"checked out".  Suppose I check out a file with revision 1.1, modify it and 
commit it, so now I have revision 1.2 in my working directory.  I run "cvs 
tag".  And 1.2 gets tagged.  Literally 1.1 is the revision I checked out.  I 
did not check out 1.2, unless commit implies check out - but I think it's 
better separate them; after all ci and co are two different commands.  Also, 
stating that a checked-out version is tagged may give the wrong impression 
that the user (unnecessarily) needs to do a "cvs co" before tagging.
2. The problem with "checked in" is that there may not be any check-in (cvs 
ci).  Suppose I check out a file for the first time and without modifying 
it, run "cvs tag".  The one and only one revision gets tagged; but there is 
never any check-in.  Stating that a checked-in revision is tagged may give 
the wrong impression that the user (unnecessarily) needs to do a "cvs ci" 
before tagging.


Anyone agrees or disagrees?

Incidentally, the entry for tag in Appendix B (page 132) says "Add a 
symbolic tag to checked out version".  I think "checked out" need to be 
re-worded, and "version" probably should be "revision".


Finally there are a number of places in cederqvist that use the phase 
"checked out".  I am not sure all mean literally "checked out".  For 
example, Sec 1.3.4 says "diff compare[s] the version (revision?) of driver.c 
that you checked out with your working copy."  Again, suppose I check out a 
file with revision 1.1, modify it and commit it, so now I have revision 1.2 
in my working directory.  I run "cvs diff".  There is no difference.  The 
comparison is NOT between 1.1 (the last revision I checked out (using cvs 
co)) and 1.2.  I think the phase "checked out" should be used with care.


Ming Kin Lai

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Liquidchild]

Guys

Finally got it all working! woho!  Only question I have left is can you
make files read only in smartCVS so that users have to select the file
for editing first, to stop other users being able to edit the same file
at the same time?

Thanks for all the help!

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS and SSH V2

[Liquidchild]

Guys

Finally got it all working! woho!  Only question I have left is can you
make files read only in smartCVS so that users have to select the file
for editing first, to stop other users being able to edit the same file
at the same time?

Thanks for all the help!

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs error: received broken pipe signal

[Mark E. Hamilton]

Yu He wrote:

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!
 
Regards,

Winnie


The cause of this is probably the failure of a loginfo script to 
function as a filter and consume stdin when it is invoked. The reason it 
doesn't happen all the time is that there is a different amount of 
information on stdin every time, depending on how many files are being 
committed. Sometimes it fills up the internal buffers and sometimes it 
doesn't.


This is documented in this section of the manual:

https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC175

--

Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
505-844-7666



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Derek Price]

Russ Sherk wrote:

>I think you can put the port into CVS_RSH.  Here is mine on winXP using plink:
>
>Z:\>echo %CVS_RSH%
>"d:\Tools\plink.exe" -ssh -pw "xx"
>Z:\>echo %CVSROOT%
>:ext:[EMAIL PROTECTED]:/var/cvs
>---
>Does this not work on linux?
>  
>

No.  It's an implementation difference.  The src/run.c piped_child
function accepts an argv array as an argument on Linux and passes that
argv directly to execvp.  Since argv[0] holds the contents of $CVS_RSH,
the system looks for a process names "$CVS_RSH", spaces, arguments, and
all.  The windows-NT/run.c pipted_child function turns it's argv into a
single string with space-delimited arguments which it then passes back
to the Windows shell for parsing, so the contents of $CVS_RSH gets
resplit on spaces.

Regards,

Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Russ Sherk]

On 7/6/05, Derek Price <[EMAIL PROTECTED]> wrote:
> Derek Price wrote:
> 
> >Also, specifying a port number to the :ext: method will be ignored at
> >best.  (it wouldn't be hard to add support for it, but no one has done so).
> >
> >
> 
> Excuse me - it would be hard to do in a general way using the current
> CVSROOT conventions since the -p option is not supported by rsh, only
> ssh.  At least, then specifying a port for rsh would no longer be
> ignored but would probably cause errors.
> 
> You can stuff the port number into an ssh wrapper script or into your
> ~/.ssh/config file for the CVS server if you need to.  Trying to stuff
> it into CVS_RSH will break, though adding support for this shouldn't be
I think you can put the port into CVS_RSH.  Here is mine on winXP using plink:

Z:\>echo %CVS_RSH%
"d:\Tools\plink.exe" -ssh -pw "xx"
Z:\>echo %CVSROOT%
:ext:[EMAIL PROTECTED]:/var/cvs
---
Does this not work on linux?

I don't use the port (-P  for plink) but the other optons work fine.
> too hard using the GNULIB argument parsing module (argv?  argz?
> command-line?  something like that), at least on feature, if anyone
> wanted to write and submit a patch.
> 
> Cheers,
> 
> Derek
> 
> 
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 
--Russ


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Liquidchild]

Guys finally seem to have got the cvs command to work, by creating a
symbolic link from the /usr/bin to the cvs within usr/local/bin, which
is not loaded on ssh scripts

However, when i go to checkout i now get the following error message:

cvs -d :ext:[EMAIL PROTECTED]:/appl/cvs checkout -P ole (in directory C:\)
cvs checkout: in directory ole:
cvs checkout: cannot open CVS/Entries for reading: No such file or
directory
cvs checkout: Updating ole
cvs [checkout aborted]: could not chdir to ole/Application: No such
file or directory

As far as I can see there is a CVS directory and and entries within
that all belonging to user gtx.

Any ideas why this is?

p.s should my root be set to the directory that contains the directory
CVSROOT?

Thanks for all the help

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs error: received broken pipe signal

[Mark D. Baushke]

-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: cvs error: received broken pipe signal

[Mark D. Baushke]

-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

[Mark D. Baushke]

-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

[Yu He]

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

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.



Regards,
Winnie


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D.
Baushke
Sent: Thursday, July 07, 2005 2:46 PM
To: Yu He
Cc: info-cvs@gnu.org; Peixiao Guo
Subject: 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-
#!/usr/local/ActiveTcl/bin/tclsh
lappend auto_path /usr/local/ActiveTcl/lib;
# commitCheck.tcl
#
set user [lindex $argv 0];
set repository [lindex $argv 1];
set fileList [lrange $argv 2 end];
puts "Attempting commit:\n${argv}\nUser:$user Repos:$repository 
Files:\n$fileList";
set checkoutAll 0;
switch $user {
   "heyu" -
   "ldong" {
  puts "Permission always granted to the mighty CVSAdmin!";
#Source cvsDb.tcl for history recording
#source [file join $env(CVSROOT) CVSROOT cvsDb.tcl]; 
puts "Recording history";
#appendHist [list action COMMIT username $user repository "$repository" 
comment "Commit: $fileList"] Y;
  exit 0;
   }

   default {
puts "Verifying permissions...";
   }
}
if { [catch {
   #Temporary controls until we can import actual scripts:
   switch -regexp $repository {
  "^/cvsroot/database/oracle/gtss2" -
  "^/cvsroot/database/oracle/gtss2/*" {
 puts "Commits to this repository currently disabled.  Contact 
administrator (4-2062) for more info."
 exit 1;
  }
   }
   switch -regexp $repository {

 "^/usr/local/cvsroot/project/dev" {
 switch $user {
"id" {
   puts "Permission Granted- Development Area";
   puts "Have a nice day."
}
default {
   puts "You don't have permission to commit to Development.";
   exit 1;
}
 }  
  }

   "^/usr/local/cvsroot/project/qa" {
 switch $user {
"id" -
"id2" -
"id3" {
   puts "Permission Granted- qa Area";
   puts "Have a nice day."
}
default {
   puts "You don't have permission to commit to qa.";
   exit 1;
}
 }  
  } 

  default {
 switch $user {
default {
   puts "You don't have permission to commit to this project 
(${repository}).  Contact administrator."
   exit 1;
}
 }
  }
   }
} ret] } {
   #Error!
   puts "CVS Server error. Email me with this info:$::errorInfo";
   exit 1;
} else {
   #Success!
   #if {$checkoutAll == 1} {
   #   exec /cvsroot/CVSROOT/checkoutAll.tcl &;
   #}
   exit 0;
}
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs

[Larry Jones]

Ryan Meder writes:
> 
> Dont know if you can help but would be great if you can, my cvs on
> mandrake is running but i am unable to set the required permission to
> access it from eclipse.

Please read the section of the manual on permissions:



If that doesn't help, please provide more details about what's going
wrong (exact error messages, what user you're trying to run as, what the
ownership and permissions are on the repository directories, etc.).

-Larry Jones

I always send Grandma a thank-you note right away.  ...Ever since she
sent me that empty box with the sarcastic note saying she was just
checking to see if the Postal Service was still working. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Read-Only Access: readers & writers files

[Larry Jones]

S I writes:
> 
> Posting a 2nd time;

Have patience, grasshopper.

> I find the 
> documentation for readers and writers files somewhat confusing and 
> ambiguous.  Could both readers and writers coexist or one at any given time?

Yes, although it doesn't make much sense.  The next to last paragraph
makes it clear that the writers file trumps the readers file.  (In other
words, if the writers file exists, then users listed in it get write
access and everyone else gets read-only access, regardless of the
contents of the readers file.)

> Question 1: Could anyone tell me when (as of what version) these files were 
> implemented?  I'm running CVS 1.11.1p1 on our Linux server and I just 
> created the 'readers' file anyway and added a user to and will ask him to 
> test it.  I don't think I could or would want to test and block myself lest 
> running the risk of undoing what I've done.  Would my current version of CVS 
> understand readers?

As far as I can recall, they've been there as long as pserver mode has. 
Certainly they're supported in 1.11.1p1 (but there are lots of bugs that
have been fixed since then, so you really should update).

> Question 2: If not, then I'm overdue an upgrade and hate to bring down the 
> server during a critical release.  Would someone please shed some light on 
> upgrading?

First, read the NEWS file for the new version to see if there have been
any changes that are going to affect you.  Usually there aren't and all
you have to do is replace your current CVS executable with the new one. 
You should run ``cvs init'' afterwards to perform any necessary updates
to your repository (but there haven't been any necessary updates -- the
most it will do is create any new administrative files -- so you don't
*have* to do it, but it's still a good idea).

-Larry Jones

They say winning isn't everything, and I've decided
to take their word for it. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Derek Price]

Matt Doar wrote:

>Derek,
>
>From the CVS manual, I see CVSROOT is indeed specified as:
>
>[:method:][[user][:[EMAIL PROTECTED]:[port]]/path/to/repository
>  
>

You specified a colon *after* the port field:

Matt Doar wrote:


>I believe you have to use:
>
>:ext:[EMAIL PROTECTED]:22:/appl/cvs/ole
>  
>

This is not allowed in the spec and I know of no clients that accept a
colon there.

Cheers,

Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Possible Spam: Re: CVS and SSH V2

[Matt Doar]

Got it: no colon allowed after a port number, and the colon between
hostname and the repository path is optional. Exactly what the manual
says. 

I'll go and get more coffee now ;-)

~Matt

> -Original Message-
> From: Derek Price [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 06, 2005 9:59 AM
> To: Matt Doar
> Cc: Todd Denniston; Liquidchild; info-cvs@gnu.org
> Subject: Re: Possible Spam: Re: CVS and SSH V2
> 
> Matt Doar wrote:
> 
> >Derek,
> >
> >From the CVS manual, I see CVSROOT is indeed specified as:
> >
> >[:method:][[user][:[EMAIL PROTECTED]:[port]]/path/to/repository
> >
> >
> 
> You specified a colon *after* the port field:
> 
> Matt Doar wrote:
> 
> 
> >I believe you have to use:
> >
> >:ext:[EMAIL PROTECTED]:22:/appl/cvs/ole
> >
> >
> 
> This is not allowed in the spec and I know of no clients that accept a
> colon there.
> 
> Cheers,
> 
> Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Possible Spam: Re: CVS and SSH V2

[Matt Doar]

Derek,

>From the CVS manual, I see CVSROOT is indeed specified as:

[:method:][[user][:[EMAIL PROTECTED]:[port]]/path/to/repository

as you say, without the colon between the hostname and the repository
path. However, SmartCVS does add a colon when putting the various fields
together to create a CVSROOT.

The relevant changes in ChangeLog around 2000/10/17 and parse_cvsroot()
in src/root.c in 1.12.9 suggest that the extra colon is still allowed.
Is it in fact deprecated?

~Matt

> -Original Message-
> From: Derek Price [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 06, 2005 9:02 AM
> To: Matt Doar
> Cc: Todd Denniston; Liquidchild; info-cvs@gnu.org
> Subject: Re: Possible Spam: Re: CVS and SSH V2
> 
> Matt Doar wrote:
> 
> >>>:ext:[EMAIL PROTECTED]:22\appl\cvs\ole
> >>>
> >>>
> >
> >I believe you have to use:
> >
> >:ext:[EMAIL PROTECTED]:22:/appl/cvs/ole
> >
> >
> 
> You are correct about the forward slashes, but not the extra colon.
> Also, specifying a port number to the :ext: method will be ignored at
> best.  (it wouldn't be hard to add support for it, but no one has done
> so).
> 
> Cheers,
> 
> Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Derek Price]

Derek Price wrote:

>Also, specifying a port number to the :ext: method will be ignored at
>best.  (it wouldn't be hard to add support for it, but no one has done so).
>  
>

Excuse me - it would be hard to do in a general way using the current
CVSROOT conventions since the -p option is not supported by rsh, only
ssh.  At least, then specifying a port for rsh would no longer be
ignored but would probably cause errors.

You can stuff the port number into an ssh wrapper script or into your
~/.ssh/config file for the CVS server if you need to.  Trying to stuff
it into CVS_RSH will break, though adding support for this shouldn't be
too hard using the GNULIB argument parsing module (argv?  argz? 
command-line?  something like that), at least on feature, if anyone
wanted to write and submit a patch.

Cheers,

Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Possible Spam: Re: CVS and SSH V2

[Derek Price]

Matt Doar wrote:

>>>:ext:[EMAIL PROTECTED]:22\appl\cvs\ole
>>>  
>>>
>
>I believe you have to use:
>
>:ext:[EMAIL PROTECTED]:22:/appl/cvs/ole
>  
>

You are correct about the forward slashes, but not the extra colon. 
Also, specifying a port number to the :ext: method will be ignored at
best.  (it wouldn't be hard to add support for it, but no one has done so).

Cheers,

Derek



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Read-Only Access: readers & writers files

[S I]

Hi

Posting a 2nd time; does anyone know the answer to my questions?  Thank you


Hi

I'm reading the manual for CVS 1.11.20 and on page 27 (preprinted on the 
page, however, the .pdf document shows it to be page 29)  I find the 
documentation for readers and writers files somewhat confusing and 
ambiguous.  Could both readers and writers coexist or one at any given time?


Question 1: Could anyone tell me when (as of what version) these files were 
implemented?  I'm running CVS 1.11.1p1 on our Linux server and I just 
created the 'readers' file anyway and added a user to and will ask him to 
test it.  I don't think I could or would want to test and block myself lest 
running the risk of undoing what I've done.  Would my current version of CVS 
understand readers?


Question 2: If not, then I'm overdue an upgrade and hate to bring down the 
server during a critical release.  Would someone please shed some light on 
upgrading?


Thanks

Steve




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Possible Spam: Re: CVS and SSH V2

[Matt Doar]

> > :ext:[EMAIL PROTECTED]:22\appl\cvs\ole

I believe you have to use:

:ext:[EMAIL PROTECTED]:22:/appl/cvs/ole

as the CVSROOT format (note extra colon and forward slashes). If you are
using the professional version of SmartCVS, it will generate the ssh
keys for you, which can be convenient.

~Matt

> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:info-cvs-
> [EMAIL PROTECTED] On Behalf Of Todd Denniston
> Sent: Wednesday, July 06, 2005 6:47 AM
> To: Liquidchild
> Cc: info-cvs@gnu.org
> Subject: Possible Spam: Re: CVS and SSH V2
> 
> Liquidchild wrote:
> >
> > Guys,
> >
> > I am trying to setup CVS and SmartCVS to allow communication with
each
> > other.
> >
> 
> smartcvs has a mailing list which might help more.
> http://www.smartcvs.com/smartcvs/community.html
> 
> > I did not set up the CVS server, our admin team has done that.  So
here
> > is what i have been doing:
> >
> > I have installed SmartCVS and entered the following into for the
> > connection string:
> >
> > :ext:[EMAIL PROTECTED]:22\appl\cvs\ole
> >
> > using public/private key auth, with the private key file pointed to
and
> > the public copied into authorized_keys.  When I test the connection
> > using smart cvs it seems fine, then when i click next to enter a
> > modules i get an "io error with details null".
> >
> 
> with regular cvs the troubleshooting starts with:
> https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_21.html#SEC189
> in your case I think the command you want to try is something like:
> ssh [EMAIL PROTECTED] "cvs -v"
> or
> ssh -l gtx 10.10.115.11 "cvs -v"
> 
> > I am really hitting a brick wall with this stuff I have never had to
> > setup CVS with SSH before, I have even tried previous clients of
WinCVS
> > and get similiar setup, again I seem to be able to login to the
server,
> > as its return command ran with 0, but when i try to checkout the
module
> > i get a "ksh: cvs not found error"
> 
> This looks like the environment of the server does not know where to
find
> the cvs executable,  you might try smartcvs's equivalent of defining
> CVS_SERVER giving it the full path the the cvs executable the admin
staff
> want you to use.
> 
> >
> > This would imply its not loading the enviroment variables hences cvs
is
> > not on the path, which i think it does not do for ssh, ie does not
load
> > the .profile, but how do you get round this.  If indeed this is (a)
> > problem.
> 
> you could try this (assuming the server is running a shell that
accepts
> bash
> scripts):
> ssh [EMAIL PROTECTED] "echo $PATH"
> ssh [EMAIL PROTECTED] ". /etc/profile;. ~/.profile;echo $PATH"
> ssh [EMAIL PROTECTED] ". /etc/profile;. ~/.profile;cvs -v"
> 
> >
> > I am unsure if i am required to do anything on the client machine
> > either, i.e set any enviroment variables.
> >
> > As you can see any help would be appreciated, and if anyone has done
> > this before i would very much like to talk to them!
> Please keep responses to me on the mailing list, thanks.
> 
> This is not intended to be direction to a gov contractor to do
anything,
> just a listing of information which _may_ answer the question which
was
> asked.
> --
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane)
> Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS and SSH V2

[Todd Denniston]

Liquidchild wrote:
> 
> Guys,
> 
> I am trying to setup CVS and SmartCVS to allow communication with each
> other.
> 

smartcvs has a mailing list which might help more.
http://www.smartcvs.com/smartcvs/community.html

> I did not set up the CVS server, our admin team has done that.  So here
> is what i have been doing:
> 
> I have installed SmartCVS and entered the following into for the
> connection string:
> 
> :ext:[EMAIL PROTECTED]:22\appl\cvs\ole
> 
> using public/private key auth, with the private key file pointed to and
> the public copied into authorized_keys.  When I test the connection
> using smart cvs it seems fine, then when i click next to enter a
> modules i get an "io error with details null".
> 

with regular cvs the troubleshooting starts with:
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_21.html#SEC189
in your case I think the command you want to try is something like:
ssh [EMAIL PROTECTED] "cvs -v"
or 
ssh -l gtx 10.10.115.11 "cvs -v"

> I am really hitting a brick wall with this stuff I have never had to
> setup CVS with SSH before, I have even tried previous clients of WinCVS
> and get similiar setup, again I seem to be able to login to the server,
> as its return command ran with 0, but when i try to checkout the module
> i get a "ksh: cvs not found error"

This looks like the environment of the server does not know where to find
the cvs executable,  you might try smartcvs's equivalent of defining
CVS_SERVER giving it the full path the the cvs executable the admin staff
want you to use.

> 
> This would imply its not loading the enviroment variables hences cvs is
> not on the path, which i think it does not do for ssh, ie does not load
> the .profile, but how do you get round this.  If indeed this is (a)
> problem.

you could try this (assuming the server is running a shell that accepts bash
scripts):
ssh [EMAIL PROTECTED] "echo $PATH"
ssh [EMAIL PROTECTED] ". /etc/profile;. ~/.profile;echo $PATH"
ssh [EMAIL PROTECTED] ". /etc/profile;. ~/.profile;cvs -v"

> 
> I am unsure if i am required to do anything on the client machine
> either, i.e set any enviroment variables.
> 
> As you can see any help would be appreciated, and if anyone has done
> this before i would very much like to talk to them!
Please keep responses to me on the mailing list, thanks.

This is not intended to be direction to a gov contractor to do anything,
just a listing of information which _may_ answer the question which was
asked.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the WarfighterThe opinions expressed here are not sanctioned by and do not necessarily 
represent those of my employer.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS log between revs - filter extra info

[Larry Jones]

Russ Sherk writes:
> 
> I have been trying to get a cvs log between revs that only shows log
> messages for what has changed between revs.  I've tried cvs log
> -rrev1:rev2 and -rrev1::rev2.  Both of which either show way too much
> info or not enough.  Where extra data is logs for files that have not
> changed.  And not enough data means that some files are excluded
> (because of the nature of : and ::).

"cvs log -S -rrev1::rev2" should do exactly what you want, provided
you're using a reasonably recent release of CVS.  If not, please be
specific about what's wrong, preferably with actual examples.

-Larry Jones

Things are never quite as scary when you've got a best friend. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server Change

[Spiro Trikaliotis]

Hello again,

* On Fri, Jun 24, 2005 at 02:51:08PM +0900 Soo-Hyun Choi wrote:

> What would be an appropriate way to merge the two CVS servers? I am
> just trying to simply copy the files (,v files) in one CVS server to
> the other CVS server. Would that cause any harm for the existing CVS
> files in the target CVS server?

Ok, in some more details:

You have a cvsroot directory, in your example, the local one is
~/cvsroot.

In that directory, you have a CVSROOT directory. In your example, this
is the ~/cvsroot/CVSROOT/ directory.

This CVSROOT directory contains some information about your repository
(for example, your modules file). If you happen to overwrite the modules
file in the "server" CVS, then the modules there would be lost (or, to
say it better, you would have to restore the file to be able to access
them like before).

Of course, I do not know if you ever changed anything in your
~/cvsroot/CVSROOT/ directory. If you did not, just move every ,v file to
the server, leaving out all files in ~/cvsroot/CVSROOT/. Make sure you
do not overwrite other files if they happen to already exist on the
server! (directories with the same name, for example).

If you made any changes to your ~/cvsroot/CVSROOT/ directory, I would
suggest you should try to find out what you changed exactly, and put
these changes in the server's CVSROOT by hand after thinking about what
you need and what you do not need (or, what might break things on the
server).

HTH,
   Spiro.

-- 
Spiro R. Trikaliotis  http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server Change

[Soo-Hyun Choi]

What would be an appropriate way to merge the two CVS servers? I am
just trying to simply copy the files (,v files) in one CVS server to
the other CVS server. Would that cause any harm for the existing CVS
files in the target CVS server?

SH-


On 6/24/05, Spiro Trikaliotis <[EMAIL PROTECTED]> wrote:
> Hello,
> 
> * On Fri, Jun 24, 2005 at 01:13:28AM + Pierre Asselin wrote:
> 
> > Soo-Hyun Choi <[EMAIL PROTECTED]> wrote:
> > > I am a beginner in using CVS, and have a question on to change the CVS 
> > > server.
> > > [ ... ]
> > > Would this work if I simply copy the CVS's ,v files with the directory
> > > to the machine S's cvsroot directory?
> >
> > Yes.  This also makes your existing sandboxes nonfunctional, so
> > be sure to delete them after committing any pending changes.
> > Check out new sandboxes from the new server after the move.
> 
> To the OP: If your server already has a CVS server (and, thus, a CVSROOT
> directory) and you want to merge both repositories into one, make sure
> you do NOT move that directory over to the server, but make sure you
> MERGE them in an appropriate way. If you just overwrite the old CVSROOT,
> you might get trouble with the data which is already stored on the
> server!
> 
> Apart from this, it works exactly like you thought (and Pierre
> confirmed). Obviously, its best if you do not try to merge two cvs
> servers into one.
> 
> Regards,
>Spiro.
> 
> --
> Spiro R. Trikaliotis  http://cbm4win.sf.net/
> http://www.trikaliotis.net/ http://www.viceteam.org/
> 
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server Change

[Spiro Trikaliotis]

Hello,

* On Fri, Jun 24, 2005 at 01:13:28AM + Pierre Asselin wrote:

> Soo-Hyun Choi <[EMAIL PROTECTED]> wrote:
> > I am a beginner in using CVS, and have a question on to change the CVS 
> > server.
> > [ ... ]
> > Would this work if I simply copy the CVS's ,v files with the directory
> > to the machine S's cvsroot directory?
> 
> Yes.  This also makes your existing sandboxes nonfunctional, so
> be sure to delete them after committing any pending changes.
> Check out new sandboxes from the new server after the move.

To the OP: If your server already has a CVS server (and, thus, a CVSROOT
directory) and you want to merge both repositories into one, make sure
you do NOT move that directory over to the server, but make sure you
MERGE them in an appropriate way. If you just overwrite the old CVSROOT,
you might get trouble with the data which is already stored on the
server!

Apart from this, it works exactly like you thought (and Pierre
confirmed). Obviously, its best if you do not try to merge two cvs
servers into one.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis  http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server Change

[Pierre Asselin]

Soo-Hyun Choi <[EMAIL PROTECTED]> wrote:
> I am a beginner in using CVS, and have a question on to change the CVS server.
> [ ... ]
> Would this work if I simply copy the CVS's ,v files with the directory
> to the machine S's cvsroot directory?

Yes.  This also makes your existing sandboxes nonfunctional, so
be sure to delete them after committing any pending changes.
Check out new sandboxes from the new server after the move.


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs update $Name: $ expansion

[Pierre Asselin]

[EMAIL PROTECTED] wrote:
> I can't get $Name: $ to expand on an update in my script below.

> It works when checking out. But, do I really have to do a checkout?

I think it works on update, *if* the working copy is missing
and the update has to get a new copy from scratch.  (And, of
course, if the sandbox has a sticky revision tag.)

So if you use $Name$ in a single file, you can get that file
to expand correctly without having to check out the entire
project.

-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Lock Files

[Mark D. Baushke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 The following script will try to only remove stale CVS locks when the
 --pid option is used. However, it does assume that /usr/bin/ps accepts
 the -p switch which may not be true on your platform. It will even try
 to clean up locks in the LockDir directory if your repository has been
 configured to use one of those instead.

Good luck,
-- Mark

: # use perl -*-Perl-*-
eval 'exec perl -S $0 ${1+"$@"}'
if 0;

=head1 NAME

find-locks.perl - locate and possibly remove stale cvs locks

=head1 SYNOPSIS

find-locks.perl [options]

Options:

  -d cvsroot  specify the local CVSROOT to be used
  -l,--list   print an ls-style of lock filenames
  -n,--dry-rundo not do anything to modify the filesystem
  -c,--clean  clean up stale locks (implies --pid)
  -p,--pidcheck lock pids for stale processes
  -h,--help   print a help message
  -v,--verboseverbose mode
  --man   a man page for this program
  --debug turn on debugging

=head1 OPTIONS

=over 8

=item B<-d cvsroot>

Specify the pathname on the local system to
the CVSROOT to be searched. The default
cvsroot is /var/cvs which may not exist on
your system.

=item B<--list>

Print an ls-style output for the lock
filename. This is useful to see who owned the
lock files that are present or are about to be
removed.

=item B<--clean>

Try to remove stale locks from the system.
This options implicitly turns on the --pid
option.

=item B<--dry-run>

Do not do anything to modify the filesystem.

If --pid is used, then some locks may be
determined to be stale. This option will
disable actually removing any stale locks.

By default, if a pid is known to be stale for
a lock, the lock will be removed. However,
unless --pid is used, no pids will be examined.

=item B<--pid>

Run the /bin/ps command locally (or, if the
lock appears to have a hostname, remotely on
the given host) in order to determine if the
process id found as a part of the lock name is
still alive or is dead.

Locks associasted with pids that do not exist
are considered to be stale.

Stale lock files will be removed unless the
--dry-run option is given on the command line.

=item B<--verbose>

Add more verbosity to indicate what is
happening.

=item B<--help>

Prints a brief help message and exits.

=item B<--man>

Prints the manual page and exists.

=item B<--debug>

Print some diagnostics that are not generally
useful for normal operation.

=back

=head1 LICENSING

find-locks.perl - locate and possibly remove stale cvs locks

Copyright (c) 2003, 2004 by Mark D. Baushke <[EMAIL PROTECTED]>
All rights reserved.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

=head1 DESCRIPTION

This program -- B -- is provided for cvs repository
administrators to try to detect cvs locks.

If given the C<--pid> option, the program will also attempt
to remove any stale locks associated with pids that no
longer exist according to the C command.

=head1 ERRORS

=over

=item CVSROOT=/var/cvs/. specifies an invalid repository.

This means that the (default) repository
(/var/cvs) provided does not exist or is not a
valid CVSROOT.

=back

=head1 AUTHOR

Mark D. Baushke E[EMAIL PROTECTED]

=cut

require 5.006;
use strict;
use warnings;
use File::Find;
use Sys::Hostname;
use Getopt::Long;
use Pod::Usage;

# Current version of this program
my $VERSION =
sprintf("%s", q$Id: find-locks.perl,v 1.6 2004/10/11 14:50:04 mdb Exp $
=~ /(\d+\.\d+)/);

# Global defaults:

my $repository = '/var/cvs';
my @pscmd_args = ('/bin/ps', '-p');
my $remote_shell = defined($ENV{'CVS_RSH'}) ? $ENV{'CVS_RSH'} : '/usr/bin/rsh';

# Option defaults
my($debug, $dry_run, $help, $filelist, $man, $try_ps, $verbose, $version) =
(0, 0, 0, 0, 0, 0, 1, 0);

GetOptions('clean|c' => sub { $dry_run = 0; $try_ps = 1; },
   'debug!' => \$debug,
   'dry-run!' => \$dry_run,
   'help|h|?' => \$help,
   'list|l' => \$filelist,
   'man' => \$man,
   'n' => sub { $dry_run = 1; },
   'pid|p' => \$try_ps,
   'quiet|q' => sub { $verbose = 0 },
   'cvsroot|d=s' => \$repository,

Re: CVS Lock Files

[Arno Schuring]

In the mean time, I could modify my shell script to do a combo on 'find' :
find /cvs/ -name *lock* && -ctime? I'll look for any locks older than 
a certain number of days.  However, the problem is that our Builds are 
automated and at 2 a.m. I'm not here watching them to call or stop the 
person who caused the problem and if the builds are successful, the 
tagging must go on.


If you are absolutely sure no people are working on the repository at 2am, 
you could consider removing all locks at 1:55 or even in the same cron 
script before the build starts. But be aware of the problems when someone 
eventually decides that 2:00 am is a perfectly sound time to checkin new 
sources... (taking into account timezone shifts and the like).



Arno


--
 np: Spock's Beard - Crack The Big Sky


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs update $Name: $ expansion

[Stuart Cooper]

> I want some sort of build identifier attached to the source I am
> building every night.

Then tag your sources every night in eg astronomical time
rev20050623 for July 23rd.
 
> $Name:$ seems logical and it does seem like the way other people do it,
> albeit with a checkout.

Yes, it only gets expanded on checkout: from info cvs:

`$Name$'
 Tag name used to check out this file.  The keyword is expanded
 only if one checks out with an explicit tag name.  For example,
 when running the command `cvs co -r first', the keyword expands to
 `Name: first'.

And you don't want users to check out the whole source tree. But if
you tag your regular build, users can update their sources with
cvs update -r rev20050623
and less stuff will get sent over the network and they'll be running with
the 20050623 'nightly build'.

They won't be able to check in changes to this since it's a non-branch tag,
but they will be able to try out nightly snapshots in this way. cvs update -A
will remove the sticky tag and bring them up to HEAD when they need to
do that.

So you associate the build identifier to your source tree through the tag.
Users won't get much clue looking at the source files themselves,
CVS/Entries in each directory will show that they've checked out the
rev20050623 tag however.

Hope this helps,
Stuart.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs update $Name: $ expansion

[kai . hendry]

I want some sort of build identifier attached to the source I am
building every night.

$Name:$ seems logical and it does seem like the way other people do it,
albeit with a checkout.

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs update $Name: $ expansion

[Stuart Cooper]

> I can't get $Name: $ to expand on an update in my script below.

> It works when checking out. But, do I really have to do a checkout?

> Because a clean checkout every night would be expensive over a crappy
> connection.

> debian$ cat test.sh
> DATE=`date +%s`
> TAG=test_$DATE
> MODULE='t'

> echo Tagging module: $MODULE with tag: $TAG

> # Snapshot the module in the repo
> cvs rtag $TAG $MODULE

> # Updating to that snapshot
> cvs update -r $TAG

> tag="$Name:  $"
> echo $tag |sed 's/^.*: //;s/ .*$//'

You're very mixed up here. The whole point of $Name: $ is you put them in
your source files and they get automagically transformed for you on checkin and
checkout. You don't use them as tag names and you shouldn't be doing sed
magic by yourself.

Common idiom (in say a Perl project)
#!/usr/bin/perl
# $Id$
use DBI;
...etc etc rest of script goes here

After the next checkin/checkout you get some nice info on the state of the file
#!/usr/bin/perl
# $Id: newDSLTests.pl,v 1.19 2005/04/15 04:00:58 scooper Exp $
use DBI;

There's a trick in C programming, something like
static char RCSId[]="$Id$";
and it gets compiled into the executable so it can later be found as
a string in the executable so you know what versions made up your compiled
software.

Take a few steps back and think about what $Id$, $Name$ are all about.

Have fun,
Stuart.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Lock Files

[S I]

Thanks.

I think(?) we've pinpointed the culprit (search for tags in Tortoise) and 
have asked the user not to execute and redo what she did to cause the 
problem.  So since last week the problem has stopped.  So I deduced that was 
the culprit.


In the mean time, I could modify my shell script to do a combo on 'find' : 
find /cvs/ -name *lock* && -ctime? I'll look for any locks older than a 
certain number of days.  However, the problem is that our Builds are 
automated and at 2 a.m. I'm not here watching them to call or stop the 
person who caused the problem and if the builds are successful, the tagging 
must go on.


Original Message Follows
From: [EMAIL PROTECTED] (Larry Jones)
To: [EMAIL PROTECTED] (S I)
CC: [EMAIL PROTECTED], info-cvs@gnu.org
Subject: Re: CVS Lock Files
Date: Wed, 22 Jun 2005 18:22:17 -0400 (EDT)
MIME-Version: 1.0
Received: from sdrc.com ([146.122.132.195]) by mc5-f16.hotmail.com with 
Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 15:22:19 -0700
Received: from sunlist.sdrc.com (sunlist.sdrc.com [146.122.142.20])by 
sdrc.com (8.9.1/8.9.1) with ESMTP id SAA16078;Wed, 22 Jun 2005 18:22:18 
-0400 (EDT)
Received: from thor.net.plm.eds.com (thor.net.plm.eds.com 
[146.122.201.250])by sunlist.sdrc.com (8.11.6+Sun/8.11.6) with ESMTP id 
j5MMMId07711;Wed, 22 Jun 2005 18:22:18 -0400 (EDT)
Received: (from [EMAIL PROTECTED])by thor.net.plm.eds.com (8.11.6/8.10.1) id 
j5MMMHF28349;Wed, 22 Jun 2005 18:22:17 -0400 (EDT)

X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
X-Mailer: ELM [version 2.5 PL3]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 22 Jun 2005 22:22:19.0839 (UTC) 
FILETIME=[DAABA4F0:01C57778]


S I writes:
>
> Thank you.  But do you see anything wrong with me manually removing such
> files?  They won't corrupt CVS or anything like that, would they?

Yes, it very well might.  You're not making any attempt to differentiate
between legitimate lock files (caused by someone currently running CVS)
and stale lock files (those left over from something horrible
happening).  Removing legitimate lock files is a recipe for disaster.
Figuring out which is which is somewhat tricky, particularly in a
script, so I strongly suggest you figure out what the horrible thing is
that's happening to leave you with stale lock files and fix it.

-Larry Jones

Just when I thought this junk was beginning to make sense. -- Calvin




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Lock Files

[Larry Jones]

S I writes:
> 
> Thank you.  But do you see anything wrong with me manually removing such 
> files?  They won't corrupt CVS or anything like that, would they?

Yes, it very well might.  You're not making any attempt to differentiate
between legitimate lock files (caused by someone currently running CVS)
and stale lock files (those left over from something horrible
happening).  Removing legitimate lock files is a recipe for disaster. 
Figuring out which is which is somewhat tricky, particularly in a
script, so I strongly suggest you figure out what the horrible thing is
that's happening to leave you with stale lock files and fix it.

-Larry Jones

Just when I thought this junk was beginning to make sense. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Lock Files

[S I]

Thank you.  But do you see anything wrong with me manually removing such 
files?  They won't corrupt CVS or anything like that, would they?


p.s. the user is using tortoise with eclipse and I think that's what caused 
it or rather doing a search for tags within tortoise.


Original Message Follows
From: "Rod Macpherson" <[EMAIL PROTECTED]>
To: "S I" <[EMAIL PROTECTED]>,
Subject: RE: CVS Lock Files
Date: Wed, 22 Jun 2005 14:12:46 -0700
MIME-Version: 1.0
Received: from exchange1.meddatahcs.com ([66.193.203.133]) by 
MC8-F38.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 
14:13:13 -0700

X-Message-Info: JGTYoYF78jG7Wo4tVlYkO3SAsLmFQsbTobegfEpTil8=
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: CVS Lock Files
Thread-Index: AcV3bmIGFH4V5F6wRG2knwRi1xbkTAAAExQg
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 22 Jun 2005 21:13:13.0132 (UTC) 
FILETIME=[330A5EC0:01C5776F]


Thing is, if this is that frequent there ottabee many reports of stray
locks. I can say we are not seeing that at all but will admit it used to
show up with a product called SmartCVS - not pointing the finger at that
product, just conveying our experience.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of S I
Sent: Wednesday, June 22, 2005 2:01 PM
To: info-cvs@gnu.org
Subject: CVS Lock Files

Hi

I've setup a cronjob on our unix server to run nightly to clean up CVS
lock
files before my build and before tagging CVS.   A user using Tortoise
accidentally caused certain folders in the repository to lock up during
my
build (about 3x's in 1 week) and tagging took about 600 minutes
(pending) to
complete until I manually removed the offensive "#cvs.*.*" files on the
server side and we cleaned up her Windows PC of any cvs.lock.tmp or
cvs.lock.folder pattern files and folders.  We seem to be OK now since I

deleted the files.

During my research I've found out that there're PERHAPS 3 ways files
COULD
be locked up UNINTENTIONALLY (NOT executing cvs admin -l):

1. Multiple users concurrently doing checkout, commit, or update.

2. Tagging?

3. And by means of an IDE such as IntelliJ or Eclipse?


Do you see anything wrong or dangerous with my unix script below?


#!/bin/sh

# Delete lock debris on cvs

find /usr/local/cvs -name "#cvs.lock*" -print | xargs rm -fdr
find /usr/local/cvs -name "#cvs.lock.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.rfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.wfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.pfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.tfl.*" -print | xargs rm -f
find /usr/local/cvs -name "cvsloc" -print | xargs rm -fdr

Thank you

Steve




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Lock Files

[Rod Macpherson]

Should be fine. When we had that issue coming up we whacked the locks
one at a time but automating should be safe. I would be a little
troubled that it's happening constantly. If asked to guess I'd pick
Tortoise over Eclipse as the culprit. We have dozens of Eclipse users
accessing our repository at all hours of the day and night and never get
that lock thingy. 

-Original Message-
From: S I [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 22, 2005 2:27 PM
To: Rod Macpherson; info-cvs@gnu.org
Subject: RE: CVS Lock Files

Thank you.  But do you see anything wrong with me manually removing such

files?  They won't corrupt CVS or anything like that, would they?

p.s. the user is using tortoise with eclipse and I think that's what
caused 
it or rather doing a search for tags within tortoise.

Original Message Follows
From: "Rod Macpherson" <[EMAIL PROTECTED]>
To: "S I" <[EMAIL PROTECTED]>,
Subject: RE: CVS Lock Files
Date: Wed, 22 Jun 2005 14:12:46 -0700
MIME-Version: 1.0
Received: from exchange1.meddatahcs.com ([66.193.203.133]) by 
MC8-F38.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun
2005 
14:13:13 -0700
X-Message-Info: JGTYoYF78jG7Wo4tVlYkO3SAsLmFQsbTobegfEpTil8=
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: CVS Lock Files
Thread-Index: AcV3bmIGFH4V5F6wRG2knwRi1xbkTAAAExQg
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 22 Jun 2005 21:13:13.0132 (UTC) 
FILETIME=[330A5EC0:01C5776F]

Thing is, if this is that frequent there ottabee many reports of stray
locks. I can say we are not seeing that at all but will admit it used to
show up with a product called SmartCVS - not pointing the finger at that
product, just conveying our experience.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of S I
Sent: Wednesday, June 22, 2005 2:01 PM
To: info-cvs@gnu.org
Subject: CVS Lock Files

Hi

I've setup a cronjob on our unix server to run nightly to clean up CVS
lock
files before my build and before tagging CVS.   A user using Tortoise
accidentally caused certain folders in the repository to lock up during
my
build (about 3x's in 1 week) and tagging took about 600 minutes
(pending) to
complete until I manually removed the offensive "#cvs.*.*" files on the
server side and we cleaned up her Windows PC of any cvs.lock.tmp or
cvs.lock.folder pattern files and folders.  We seem to be OK now since I

deleted the files.

During my research I've found out that there're PERHAPS 3 ways files
COULD
be locked up UNINTENTIONALLY (NOT executing cvs admin -l):

1. Multiple users concurrently doing checkout, commit, or update.

2. Tagging?

3. And by means of an IDE such as IntelliJ or Eclipse?


Do you see anything wrong or dangerous with my unix script below?


#!/bin/sh

# Delete lock debris on cvs

find /usr/local/cvs -name "#cvs.lock*" -print | xargs rm -fdr
find /usr/local/cvs -name "#cvs.lock.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.rfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.wfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.pfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.tfl.*" -print | xargs rm -f
find /usr/local/cvs -name "cvsloc" -print | xargs rm -fdr

Thank you

Steve




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Lock Files

[Rod Macpherson]

Thing is, if this is that frequent there ottabee many reports of stray
locks. I can say we are not seeing that at all but will admit it used to
show up with a product called SmartCVS - not pointing the finger at that
product, just conveying our experience. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of S I
Sent: Wednesday, June 22, 2005 2:01 PM
To: info-cvs@gnu.org
Subject: CVS Lock Files

Hi

I've setup a cronjob on our unix server to run nightly to clean up CVS
lock 
files before my build and before tagging CVS.   A user using Tortoise 
accidentally caused certain folders in the repository to lock up during
my 
build (about 3x's in 1 week) and tagging took about 600 minutes
(pending) to 
complete until I manually removed the offensive "#cvs.*.*" files on the 
server side and we cleaned up her Windows PC of any cvs.lock.tmp or 
cvs.lock.folder pattern files and folders.  We seem to be OK now since I

deleted the files.

During my research I've found out that there're PERHAPS 3 ways files
COULD 
be locked up UNINTENTIONALLY (NOT executing cvs admin -l):

1. Multiple users concurrently doing checkout, commit, or update.

2. Tagging?

3. And by means of an IDE such as IntelliJ or Eclipse?


Do you see anything wrong or dangerous with my unix script below?


#!/bin/sh

# Delete lock debris on cvs

find /usr/local/cvs -name "#cvs.lock*" -print | xargs rm -fdr
find /usr/local/cvs -name "#cvs.lock.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.rfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.wfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.pfl.*" -print | xargs rm -f
find /usr/local/cvs -name "#cvs.tfl.*" -print | xargs rm -f
find /usr/local/cvs -name "cvsloc" -print | xargs rm -fdr

Thank you

Steve




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Pierre Asselin]

Dennis von Ferenczy <[EMAIL PROTECTED]> wrote:

> Thanks for your advice. But what will be the advantage? If I get you right,
> then I would have to do a commit every time I want to test the changes in my
> scripts,

Yes.

> even if I have changed only a single line of code

Yes.

> - and even if the code is buggy.

Yes.  If you commit a bug, fix it and commit again.
Try not to commit buggy code, but if it happens once in a while
it's not that big a deal.

You will want to tag the project when you believe there are no
bugs, so you have a well-defined baseline to begin serious testing.
You can also create a stabilization branch where you will do the
bug fixes, or you can wait till you are ready to move the code to the
production server.  You *must* tag the state that you move to production
and you *must* fix any post-release bugs on a branch, to isolate
production from continuing work on the trunk.

Having a trunk and one active branch will complicate the
commitinfo script but it's doable.  Can you run two instances
of the testing server ?  Then your loginfo hook can maintain
two sandboxes, one on the trunk and one on the active release
branch.  You can use a floating tag name for the active branch
to avoid rewriting the loginfo script all the time.  There are
ways;  it's just normal hacking.


> Right now I work locally, have the files mirrored using SSH
> (I'm not sure if cvs can use SSH) can immediately try my changes and if
> everything works as desired I do a commit.

So you upload instead of cvs-commit, and something goes wrong right
at that step and the remote sandbox loses its CVS subdirectories.
Which is worse ?


> Like this I can always be sure,
> that code in the repository is actually code that is working correctly.

No, the code can still be buggy, just not obviously so.  You will
commit buggy code every once in a while even if you can test
before committing.  Like I said, it's not that big a deal.

The best solution would be to fix your IDE's habit of clobbering
the remote CVS directories.  Failing that, my proposal is quite
workable once you get used to it.


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS-Directories disappear when uploading per SFTP-Client

[Dennis von Ferenczy]

> 
> If I understand your workflow it goes something like this:
> 1) cvs checkout on server machine.
> 2) sftp checkout to dev machine.
> 3) make mods and test on dev machine.
> 4) sftp checkout back to server machine.
> 5) cvs commit changes on server machine.
> 6) sftp changes from dev machine to the production web server.
> 

I am sorry, that my comment was maybe a little bit contradictory. My current
workflow is the following:

1) cvs checkout on dev machine (remote, purely development no production,
debian linux, cvs "Concurrent Versions System (CVS) 1.12.9 (client/server)")
2) sftp checkout on local machine (no-server, only IDE running, windows)
3) file changes automatically mirrored by SFTP-client to a web-accessible
directory on the dev machine (remote)
4) testing on dev machine (remote, internet-application, controlled using
browser)
5) if everything is working fine -> commit

So the producion server is in no way concerned by this workflow. There are
just two machines: The local Windows machine with the IDE running and the
remote Unix development machine where the application is hosted

so the following workflow wouldn't work for me, because the local machine is
not a web server.

> If you setup cvs, using ssh, you should be able to change 
> your workflow to:
> 1} cvs checkout on dev machine.
> 2} make mods and test on dev machine.
> 3} cvs commit changes on dev machine.
> 4} login to the production area, issue `cvs update`.





___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS-Directories disappear when uploading per SFTP-Client

[Dennis von Ferenczy]

> >
> It sounds like you use your production environment for 
> testing. Good configuration management practises dictate that 
> you should never do that.
> 
> Configure your local machine to behave the same way as the 
> production machine. Test on your local machine.
> 
> If you do not do this, then sooner or later you *will* crash 
> your production machine.

no, the server I am talking about is a pure development server (although it
is not a local machine) configured to behave like the production machine.




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Todd Denniston]

Dennis von Ferenczy wrote:
> 
> >
> > Dennis von Ferenczy <[EMAIL PROTECTED]> wrote:
> >

> > Yes.  Get a CVS client for your local machine and do your cvs
> > commits from there behind the IDE's back.  On the CVS server
> > == web server, use the loginfo hook to keep a reference
> > sandbox up to date, from which the web site operates.
> > https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158
> >
> 
> Thanks for your advice. But what will be the advantage? If I get you right,
> then I would have to do a commit every time I want to test the changes in my
> scripts, even if I have changed only a single line of code - and even if the
> code is buggy. 

OK, your above comment and your following comment seem to contradict each
other.
If you are testing locally (on your development box, using your sand box)
why would you need to commit to the Production CVS/WEB server with a posibly
broken change set? If you can currently test on your local box, then make
your checkout to that location, do your mods and tests, then when you are
done, and have a good change set, do a commit.
What you have been doing with SFTP is half of what CVS will do for you, IF
YOU LET IT.

> Right now I work locally, have the files mirrored using SSH
> (I'm not sure if cvs can use SSH) can immediately try my changes and if
> everything works as desired I do a commit. Like this I can always be sure,
> that code in the repository is actually code that is working correctly.

If you re-read my message you should see that CVS can use ssh, but you have
to tell CVS to use ssh instead of rsh by setting `export CVS_RSH=ssh` (in a
unix environment, there is a way to do it with cvsnt as well, but you will
need to read their wiki[1]). 
BTW I suggest you run `cvs version` in your windows environment and include
its output with your next email, it might help us answer some of the
questions you have.


If I understand your workflow it goes something like this:
1) cvs checkout on server machine.
2) sftp checkout to dev machine.
3) make mods and test on dev machine.
4) sftp checkout back to server machine.
5) cvs commit changes on server machine.
6) sftp changes from dev machine to the production web server.

If you setup cvs, using ssh, you should be able to change your workflow to:
1} cvs checkout on dev machine.
2} make mods and test on dev machine.
3} cvs commit changes on dev machine.
4} login to the production area, issue `cvs update`.

if steps 3) and 2} involve ftping files to the production webserver, I
suggest you spend time rereading Jim Hyslop's email. Best practices usually
involve having a test 'server'/setup where you test all your work and when
it is working then you commit & tag, and then login to the production area
and do a `cvs update` from a known working tag. 

[1] http://www.cvsnt.org/wiki

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Jim Hyslop]

Dennis von Ferenczy wrote:

Yes.  Get a CVS client for your local machine and do your cvs 
commits from there behind the IDE's back.  On the CVS server 
== web server, use the loginfo hook to keep a reference 
sandbox up to date, from which the web site operates.

https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158

   



Thanks for your advice. But what will be the advantage? If I get you right,
then I would have to do a commit every time I want to test the changes in my
scripts, even if I have changed only a single line of code - and even if the
code is buggy. Right now I work locally, have the files mirrored using SSH
(I'm not sure if cvs can use SSH) can immediately try my changes and if
everything works as desired I do a commit. Like this I can always be sure,
that code in the repository is actually code that is working correctly.
 

It sounds like you use your production environment for testing. Good 
configuration management practises dictate that you should never do that.


Configure your local machine to behave the same way as the production 
machine. Test on your local machine.


If you do not do this, then sooner or later you *will* crash your 
production machine.


--
Jim



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS-Directories disappear when uploading per SFTP-Client

[Dennis von Ferenczy]

> 
> Dennis von Ferenczy <[EMAIL PROTECTED]> wrote:
> 
> > [ ... ]
> > The problem is the following: 
> > the cvs server is at the same time the web server where the 
> > application runs. So I have to checkout to the web server. 
> But: My IDE 
> > runs locally on my machine and it needs the complete source code to 
> > enable it to use code completion etc. Between my local 
> machine and the 
> > server there is only a DSL connection so I have the local changes 
> > mirrored to the web server (using the SFTP client) and then 
> do the commit from the web server.
> > Any better ideas?
> 
> Yes.  Get a CVS client for your local machine and do your cvs 
> commits from there behind the IDE's back.  On the CVS server 
> == web server, use the loginfo hook to keep a reference 
> sandbox up to date, from which the web site operates.
> https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158
> 

Thanks for your advice. But what will be the advantage? If I get you right,
then I would have to do a commit every time I want to test the changes in my
scripts, even if I have changed only a single line of code - and even if the
code is buggy. Right now I work locally, have the files mirrored using SSH
(I'm not sure if cvs can use SSH) can immediately try my changes and if
everything works as desired I do a commit. Like this I can always be sure,
that code in the repository is actually code that is working correctly.




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Pierre Asselin]

Dennis von Ferenczy <[EMAIL PROTECTED]> wrote:

> [ ... ]
> The problem is the following: 
> the cvs server is at the same time the web server where the application
> runs. So I have to checkout to the web server. But: My IDE runs locally on
> my machine and it needs the complete source code to enable it to use code
> completion etc. Between my local machine and the server there is only a DSL
> connection so I have the local changes mirrored to the web server (using the
> SFTP client) and then do the commit from the web server. 
> Any better ideas?

Yes.  Get a CVS client for your local machine and do your cvs commits
from there behind the IDE's back.  On the CVS server == web server,
use the loginfo hook to keep a reference sandbox up to date, from
which the web site operates.
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Arno Schuring]

The problem is the following:
the cvs server is at the same time the web server where the application
runs. So I have to checkout to the web server. But: My IDE runs locally on
my machine and it needs the complete source code to enable it to use code
completion etc. Between my local machine and the server there is only a 
DSL
connection so I have the local changes mirrored to the web server (using 
the

SFTP client) and then do the commit from the web server.
Any better ideas?


Let CVS mirror the changes to the webserver. CVS is perfectly capable of 
handling multiple copies itself. There are some options you can consider:


- Since you have stfp access, I'm assuming you have ssh shell access as 
well. Go into your webserver's content directory and do a cvs checkout 
there. Each time you want to update the site, simply perform a cvs update on 
the webserver. Maybe change the settings of your webserver to ignore/hide 
the CVS/ directories (apache: modify the .htaccess file)


- This can be automated (but DON'T do that on your production site, since 
every mistake that gets committed to the repository will immediately be seen 
on the web), see 
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC177 (keeping 
a checked out copy)


- If somehow your sftp program/filesystem/ghost in the machine insists on 
removing the CVS/ directories when you upload, try uploading from another 
sandbox (so basically you will have two sandboxes on your local pc: one for 
'work' and one for 'upload'). The 'upload' copy can be created with cvs 
export, if you want.



Arno


--
 np: Dead Can Dance - Sanvean 



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Todd Denniston]

Dennis von Ferenczy wrote:
> 
> >
> > Let's see if I got this straight:
> > 1)  You start with the CVS/ directories present.
> > 2)  You run an SFTP client.
> > 3)  The CVS/directories are gone.
> >
> > Based on these facts, I would say that the SFTP client
> > removed the directories.
> 
> although this sounds rather unlikely to me, I will have a look at it and try
> another SFTP client (currently I am using WinSCP 3.7.5)
> 
> >
> > May I ask why you are mixing CVS and sftp ?  Why can't you
> > have a CVS sandbox checked out on the machine from which you
> > were uploading changes ?  Instead of uploading, you would
> > just cvs commit from there.
> 
> The problem is the following:
> the cvs server is at the same time the web server where the application
> runs. So I have to checkout to the web server. But: My IDE runs locally on
> my machine and it needs the complete source code to enable it to use code
> completion etc. Between my local machine and the server there is only a DSL
> connection so I have the local changes mirrored to the web server (using the
> SFTP client) and then do the commit from the web server.
> Any better ideas?
> 

Try having your repository as a remote repo[2] using ssh as your :ext:
method[1] with CVS for your local work and use ssh to login and do either
`cvs update` or `cvs export` on your web server.
Note that depending on your IDE you may be able to integrate it directly
into calling CVS[3], if you have cvs setup as a remote repository.

[1] https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC28
i.e., set CVS_RSH=ssh #or your systems ssh client.
note for the example shown I believe you will want to replace all rsh calls
with ssh.

[2] https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC26

[3]
http://www.cvsnt.org/wiki/ThirdPartyTools#head-fc58f200cea8e136e0be4d945fcee085858fe670


-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS-Directories disappear when uploading per SFTP-Client

[Dennis von Ferenczy]

> 
> Let's see if I got this straight:
> 1)  You start with the CVS/ directories present.
> 2)  You run an SFTP client.
> 3)  The CVS/directories are gone.
> 
> Based on these facts, I would say that the SFTP client 
> removed the directories.

although this sounds rather unlikely to me, I will have a look at it and try
another SFTP client (currently I am using WinSCP 3.7.5)

> 
> May I ask why you are mixing CVS and sftp ?  Why can't you 
> have a CVS sandbox checked out on the machine from which you 
> were uploading changes ?  Instead of uploading, you would 
> just cvs commit from there.

The problem is the following: 
the cvs server is at the same time the web server where the application
runs. So I have to checkout to the web server. But: My IDE runs locally on
my machine and it needs the complete source code to enable it to use code
completion etc. Between my local machine and the server there is only a DSL
connection so I have the local changes mirrored to the web server (using the
SFTP client) and then do the commit from the web server. 
Any better ideas?




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS vs Visual SourceSafe

[Rod Macpherson]

Probably 99% of the "how do I lock" questions are CVS noobs
uncomfortable with the general answer: you don't. 

Bottom line: locking introduces development bottlenecks with almost no
benefit. In fact it's a false sense of coordination where changes are
blown away on a regular basis: bugs magically reappear. 

The exceptions are binary files. Can't merge so concurrent edits are
wasted effort. CVS allows files to be locked in that case but a better
solution is using edit/unedit. You can list editors. 

The best solution, IMO, would be to have an exclusive editor (xedit)
where commits could only be executed by that user until xunedit was
called. That could be overridden with commit -F so it would not be a
true lock. The exclusive editor would be part of the status so an IDE
could show files as being held by an exclusive editor -- I hesitate to
say "lock" because it's more of a courtesy thing than a hard lock. 




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Bittner,Peter
Sent: Monday, June 20, 2005 2:19 AM
To: info-cvs@gnu.org
Subject: RE: CVS vs Visual SourceSafe

Edwin,

> While there is much to say for the concurrent versioning philosophy,
> there are also many situations where it is not the optimal solution.
> (As represented by the fact that every so often this list receives
> question about how to exclusively lock a file using CVS).

Of course, you are right. (Really, I meant: Do I need concurrent access
to sources or is it okay to only have exclusive access by locking?)

Subversion, in the current version, does provide exclusive locking. And,
doesn't CVSNT also do it?

It might be worth and interesting to check out some comparisons. The
following ones are those I found on the web: (Anyone knowing others?)

General:
- http://better-scm.berlios.de/comparison/comparison.html
- http://www.pushok.com/soft_svn_vscvs.php

CVSNT vs. CVS:
- http://www.cvsnt.com/cvspro/compare.htm

Cheers, Peter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS vs Visual SourceSafe

[Bittner,Peter]

Edwin,

> While there is much to say for the concurrent versioning philosophy,
> there are also many situations where it is not the optimal solution.
> (As represented by the fact that every so often this list receives
> question about how to exclusively lock a file using CVS).

Of course, you are right. (Really, I meant: Do I need concurrent access
to sources or is it okay to only have exclusive access by locking?)

Subversion, in the current version, does provide exclusive locking. And,
doesn't CVSNT also do it?

It might be worth and interesting to check out some comparisons. The
following ones are those I found on the web: (Anyone knowing others?)

General:
- http://better-scm.berlios.de/comparison/comparison.html
- http://www.pushok.com/soft_svn_vscvs.php

CVSNT vs. CVS:
- http://www.cvsnt.com/cvspro/compare.htm

Cheers, Peter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS vs Visual SourceSafe

[Bittner,Peter]

Hi!

I think there is not much decide about SourceSafe yes or no.
MS SourceSafe is old, not maintained by Microsoft any more (they are
about to develop a replacement as far as I have heard), the use locking
instead of concurrency, etc. etc.

No, really, you'd better decide between:

- CVS  (https://www.cvshome.org/)
- CVSNT  (http://www.cvsnt.com/cvspro/ - http://www.cvsnt.org/wiki/)
- Subversion  (http://subversion.tigris.org/)

You should ask yourself:

- Do I want several developers to be able to work on the same sources at
the same time? (all of them do this, MSSS does not)

-  Do I want to be able to do check-in/check-out over HTTP/HTTPS? (I
think, for this Subversion would be the best choice)

- Do I want my developers to have clients available on any platform? (I
would say then the ranking might be somewhat like: 1. CVSNT/CVS, 2.
Subversion, 3. MSSS)

(Note: CVSNT is _not_ for Windows NT only, more than that it is a
somewhat more advanced CVS system, available on almost all platforms, as
is CVS.)

Best regards,
Peter


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
pioioi
Sent: Monday, June 20, 2005 7:32 AM
To: info-cvs@gnu.org
Subject: CVS vs Visual SourceSafe

Help me!~~ Help me!~ I need you guys advice.

I have to make a decision between CVS and Visual SourceSafe..

What are advantages and disadvantages over each other program??

And which one is better for stability?

(It doesn't matter free or not.)

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS-Directories disappear when uploading per SFTP-Client

[Pierre Asselin]

Dennis von Ferenczy <[EMAIL PROTECTED]> wrote:

> When I do a checkout everything is fine and a "CVS" directory is present in
> every directory of the checked out module. However as soon as I upload a
> changed version of of my code using my SFTP-Client the CVS-Directory
> disappears from the directory to which I have uploaded the file. As a result
> of this CVS always thinks that the directory is not yet under CVS-control. 

Let's see if I got this straight:
1)  You start with the CVS/ directories present.
2)  You run an SFTP client.
3)  The CVS/directories are gone.

Based on these facts, I would say that the SFTP client removed
the directories.

May I ask why you are mixing CVS and sftp ?  Why can't you have a
CVS sandbox checked out on the machine from which you were
uploading changes ?  Instead of uploading, you would just
cvs commit from there.

-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Lock Errors

[S I]

Thank you all for your help.

I found out(by googling) this was the case and cvs had left out debris of 
#cvs.rfl.blah.blah files in certain directories on the server as well as 
cvs.lock files on the user's pc.  Once we made sure she had checked in all 
his work, we manually deleted the .lock files and everything SEEMS to be ok 
now.  Thank you for the useful information.  It's always good to know more 
:)


Thanks again

Original Message Follows
From: "Arthur Barrett" <[EMAIL PROTECTED]>
To: "S I" <[EMAIL PROTECTED]>,
Subject: RE: CVS Lock Errors
Date: Fri, 17 Jun 2005 10:32:42 +1000
MIME-Version: 1.0
Received: from mail.march-hare.com ([61.88.121.170]) by mc5-f15.hotmail.com 
with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 17:46:19 -0700

X-Message-Info: JGTYoYF78jH8W+5Xll35zI9kPqLdLWobjEchZ/b194k=
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: CVS Lock Errors
Thread-Index: AcVyqNiqBr4ZKrETSUePSnLXucct9QAKkT6N
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 17 Jun 2005 00:46:19.0718 (UTC) 
FILETIME=[F9F60E60:01C572D5]


Steven,

This is quite a common problem (at least for some people).

CVS locks at the directory level on the server, by creating a "lock file".  
If the server process terminates unexpectedly (eg: kill -9) then the "lock 
file" is left in place.  To "unlock" your repository remove the lock files.


CVSNT (open source, GPL, Linux, Unix, Mac, Windows, just like CVS) resolves 
this by having a separate lock server process.  If the client process dies 
so do the locks.  It also means that checkout and update are atomic.  CVSNT 
also includes "chacl", "lsacl" etc for setting access control lists on 
branhes etc which I notice was another question of yours in another thread).


If you are using Tortoise on the client - by default Tortoise uses the CVSNT 
client (it comes with Tortoise) - you will get better integration if you use 
CVSNT server and Tortoise with CVSNT...


If you are interested in CVSNT please refer questions to the CVSNT 
newsgroup:

http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
or
news://news.cvsnt.org/support.cvsnt

Regards,


Arthur Barrett


-Original Message-
From:	[EMAIL PROTECTED] on behalf of S 
I

Sent:   Fri 6/17/2005 5:35 AM
To: info-cvs@gnu.org
Cc:
Subject:CVS Lock Errors

Hi

I have a 2nd question:

A user using Tortoise window's client using :pserver to the linux box,
executed the commad searching for tags.  Not a specific tag but all tags in
the repository.  The command's been running for about 15 hours now, locking
cvs, and not allowing anyone else to tag.  We can update, commit, etc but
not tag. And I do need to tag my build today.

When I try to tag, I get the error msg that so & so user has it locked. When
I do -cvs admin -U, the server says waiting for the user's lock, etc.

On the linux server side, I thought it was a ps process I could kill...but
NONE!

How can I kill this annoying process?  I told him to delete all his working
folders, reboot, and check out fresh and anew again.

Any suggestions?

Thank you

Steven




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Lock Errors

[S I]

I'm ok now. Oddly I didn't find any cvs processes running on the unix 
server.  So I cut & paste the error msgs into google and found out cvs.locks 
were created by the user, inadvertently, and we had to delete them manually. 
 Thank you very much for the info and your time. :)


Original Message Follows
From: Todd Denniston <[EMAIL PROTECTED]>
To: S I <[EMAIL PROTECTED]>
CC: info-cvs@gnu.org
Subject: Re: CVS Lock Errors
Date: Thu, 16 Jun 2005 19:13:39 -0500
MIME-Version: 1.0
Received: from mail.ssa.crane.navy.mil ([164.227.42.3]) by 
mc3-f29.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 
17:16:50 -0700
Received: from ssa.crane.navy.mil ([EMAIL PROTECTED] 
[164.227.42.142]) by mail.ssa.crane.navy.mil  with ESMTP id TAA26924; Thu, 
16 Jun 2005 19:14:42 -0500

X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
Organization: Code 6067, NSWC Crane
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.25glock1 i686)
X-Accept-Language: en
References: <[EMAIL PROTECTED]>
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 17 Jun 2005 00:16:51.0102 (UTC) 
FILETIME=[DBC8ABE0:01C572D1]


S I wrote:
>
> Hi
>
> I have a 2nd question:
>
> A user using Tortoise window's client using :pserver to the linux box,
> executed the commad searching for tags.  Not a specific tag but all tags 
in
> the repository.  The command's been running for about 15 hours now, 
locking

> cvs, and not allowing anyone else to tag.  We can update, commit, etc but
> not tag. And I do need to tag my build today.
>
> When I try to tag, I get the error msg that so & so user has it locked. 
When

> I do -cvs admin -U, the server says waiting for the user's lock, etc.
>
> On the linux server side, I thought it was a ps process I could 
kill...but

> NONE!

If it is a process that is still running,  you should be able to find the
process with
`ps options |grep cvs` where options are either "aux" or "ef".

>
> How can I kill this annoying process?  I told him to delete all his 
working

> folders, reboot, and check out fresh and anew again.

If he has done all the those things, which should be unnecessary, and the ps
netted nothing ... some how cvs (on the server) was terminated while he was
doing his tag search and was not given a chance to clean up after itself.

>
> Any suggestions?
>
WARNING USE AT YOUR OWN RISK * WARNING USE AT YOUR OWN RISK *
with all the above going on I would:
1) configure inetd or xinetd to not run any more cvs processes while I
figure out what is going on. (and restart [x]inetd)
2) stop any currently running cvs instances (under linux on the server)
`killall -SIGTERM cvs;echo "nice kill done"; \
sleep 60; killall -9 cvs; echo "lets se-em survive that"`
#if you get any output before the "nice kill done" echo,
#there were no cvs's running.
3) make a backup of the repository.
4) run Donald Sharp's check_cvs script to see what if anything is amiss with
the repository
5) take note of and delete any locks check_cvs finds.
6) decide if you want to fix anything else check_cvs finds.
7) take some guesses as to how it got into this state
(this seems like a very weird state to me, it would probably be good to let
the mailing list know what version of cvs you are running on the server and
Tortoise. have you ever had this search for all tags action work in the
past?)
8) put the system back on line for cvs work. reconfigure [x]inetd to run cvs
pserver and restart [x]inetd.

9) you might want to check and make sure everyone is accessing the repo
through pserver or ext (to the same server machine) and that no one is
accessing it using a filesystem method.

WARNING USE AT YOUR OWN RISK * WARNING USE AT YOUR OWN RISK *
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Lock Errors

[Arthur Barrett]

Steven,

This is quite a common problem (at least for some people).

CVS locks at the directory level on the server, by creating a "lock file".  If 
the server process terminates unexpectedly (eg: kill -9) then the "lock file" 
is left in place.  To "unlock" your repository remove the lock files.

CVSNT (open source, GPL, Linux, Unix, Mac, Windows, just like CVS) resolves 
this by having a separate lock server process.  If the client process dies so 
do the locks.  It also means that checkout and update are atomic.  CVSNT also 
includes "chacl", "lsacl" etc for setting access control lists on branhes etc 
which I notice was another question of yours in another thread).

If you are using Tortoise on the client - by default Tortoise uses the CVSNT 
client (it comes with Tortoise) - you will get better integration if you use 
CVSNT server and Tortoise with CVSNT...

If you are interested in CVSNT please refer questions to the CVSNT newsgroup:
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
or
news://news.cvsnt.org/support.cvsnt

Regards,


Arthur Barrett


-Original Message-
From:   [EMAIL PROTECTED] on behalf of S I
Sent:   Fri 6/17/2005 5:35 AM
To: info-cvs@gnu.org
Cc: 
Subject:CVS Lock Errors

Hi

I have a 2nd question:

A user using Tortoise window's client using :pserver to the linux box, 
executed the commad searching for tags.  Not a specific tag but all tags in 
the repository.  The command's been running for about 15 hours now, locking 
cvs, and not allowing anyone else to tag.  We can update, commit, etc but 
not tag. And I do need to tag my build today.

When I try to tag, I get the error msg that so & so user has it locked. When 
I do -cvs admin -U, the server says waiting for the user's lock, etc.

On the linux server side, I thought it was a ps process I could kill...but 
NONE!

How can I kill this annoying process?  I told him to delete all his working 
folders, reboot, and check out fresh and anew again.

Any suggestions?

Thank you

Steven




___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs





___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Lock Errors

[Todd Denniston]

S I wrote:
> 
> Hi
> 
> I have a 2nd question:
> 
> A user using Tortoise window's client using :pserver to the linux box,
> executed the commad searching for tags.  Not a specific tag but all tags in
> the repository.  The command's been running for about 15 hours now, locking
> cvs, and not allowing anyone else to tag.  We can update, commit, etc but
> not tag. And I do need to tag my build today.
> 
> When I try to tag, I get the error msg that so & so user has it locked. When
> I do -cvs admin -U, the server says waiting for the user's lock, etc.
> 
> On the linux server side, I thought it was a ps process I could kill...but
> NONE!

If it is a process that is still running,  you should be able to find the
process with 
`ps options |grep cvs` where options are either "aux" or "ef".

> 
> How can I kill this annoying process?  I told him to delete all his working
> folders, reboot, and check out fresh and anew again.

If he has done all the those things, which should be unnecessary, and the ps
netted nothing ... some how cvs (on the server) was terminated while he was
doing his tag search and was not given a chance to clean up after itself.

> 
> Any suggestions?
> 
WARNING USE AT YOUR OWN RISK * WARNING USE AT YOUR OWN RISK * 
with all the above going on I would:
1) configure inetd or xinetd to not run any more cvs processes while I
figure out what is going on. (and restart [x]inetd)
2) stop any currently running cvs instances (under linux on the server)
`killall -SIGTERM cvs;echo "nice kill done"; \
sleep 60; killall -9 cvs; echo "lets se-em survive that"`
#if you get any output before the "nice kill done" echo, 
#there were no cvs's running.
3) make a backup of the repository.
4) run Donald Sharp's check_cvs script to see what if anything is amiss with
the repository
5) take note of and delete any locks check_cvs finds.
6) decide if you want to fix anything else check_cvs finds.
7) take some guesses as to how it got into this state 
(this seems like a very weird state to me, it would probably be good to let
the mailing list know what version of cvs you are running on the server and
Tortoise. have you ever had this search for all tags action work in the
past?)
8) put the system back on line for cvs work. reconfigure [x]inetd to run cvs
pserver and restart [x]inetd.

9) you might want to check and make sure everyone is accessing the repo
through pserver or ext (to the same server machine) and that no one is
accessing it using a filesystem method.

WARNING USE AT YOUR OWN RISK * WARNING USE AT YOUR OWN RISK * 
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs query

[Alexander Taler]

> "Hridyesh" == Hridyesh Pant <[EMAIL PROTECTED]> writes:
  Hridyesh> Hi I need to generate a log of files, which are changed in most
  Hridyesh> number of times between two dates.  Is there any cvs command which
  Hridyesh> can give me the list of files (descending or ascending order) which
  Hridyesh> are most number of times changed between two dates?  Please help me

Hi, if you want to do this often, and need to write a custom
script, LibCVS may be able to help you.  Or for a one shot
solution, you could try and parse the output of the cvs log
command, which takes date options.  Read the cvs info pages.

Alex

-- 
https://savannah.gnu.org/projects/libcvs-specAccess CVS through a library.
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
convince your customer that pserver access to a CVS server is, if not
*actually* the work of the devil, then pretty similar -- Derek Price


___
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

[Spiro Trikaliotis]

Hello Mark,

first of all, thanks for your answer.

* On Sun, Jun 05, 2005 at 09:39:07PM -0700 Mark D. Baushke wrote:
 
> Read https://www.cvshome.org/docs/manual/cvs-1.12.12/cvs_18.html#SEC188

Yes, I had already done this.

> Add the line 'UseNewInfoFmtStrings=yes' to CVSROOT/config

I had already done this, too.

> Use:
> 
> DEFAULT Mail -s "%p %s" [EMAIL PROTECTED]
> 
> and you should get something that approximates your old behavior.

Thanks, that did the trick. Re-reading the relevant section, I
understand it now. I'm not sure why I was confused yesterday; perhaps, I
should have wait until today before I wrote to this mailing list.

Thank you very much!

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis  http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/


___
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

[Mark D. Baushke]

-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: cvs client unable to see files added by TortoiseCVS

[Andy Jones]

Apologies if I am telling you something you already know, but updating
the repository does not automatically update all the sandboxes.

In order to get an updated sandbox/working area, the normal thing to
do is 'cvs update'.  You can do 'checkout', as you are doing, it's
normally much the same thing.

On 02/06/05, Edward Moon <[EMAIL PROTECTED]> wrote:
> cvs server: cvs 1.11.17 on a Redhat Linux AS server
> cvs client1: TortoiseCVS v1.6.14 (which uses CVSNT 2.0.41a) on WindowsXP
> cvs client2: cvs-1.11.1p1 on Redhat Linux AS
> 
> If client1 adds files to the cvs repository using TortoiseCVS, the
> added files are not seen by client2 (i.e. cvs update doesn't fetch the
> files).
> 
> The only way I have found to force client2 to fetch the files is to
> issue a cvs -d :pserver:[EMAIL PROTECTED]:/vault co MODULE/DIR/TO/ADDED/FILES
> 
> I've tried updating the client cvs version to 1.11.20 and have not
> seen any change in behavior.
> 
> Is this an issue with TortoiseCVS/CVSNT or something with the
> configuration of the cvs server?
> 
> Thanks,
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 


-- 
Give me ambiguity, or give me something else.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS misc questions

[Pierre Asselin]

Fabio Miranda Hamburger <[EMAIL PROTECTED]> wrote:

> I have a misc list of CVS questions regarding web development:

> 1. Let's say you have 10 developers uploading files from dreamweaver to a
> apache server (let's assume no testin). If you implement CVS, how can you
> implement CVS in these situation when you have designer and developer
> without unix knowledgement and without shell access ?

I would use TortoiseCVS.  You will probably have to install it on their
computers.  If necessary, write a detailed memo on where to download
the files and what buttons to click to perform the install.

You should also place the first version of your site in CVS yourself.
CVS is very easy to use once everything is set up, but starting something
takes more work, which you don't want to impose on your web developers.


> 2. Where can I find 'best practise' articles about control versioning? how
> to know you reach a milestone? well, in fact, how to define one?, how to
> assign number to the versions with a logic sense? like linux kernel
> versioning

That's a long story, and it may not apply to your web site since
from what you say the files get deployed to a live server without
going through a formal testing stage.  Only you can tell when you've
reached a milestone.  When you do, the simplest thing is to tag the
project so you can return to that state if need be.


> 3. How to deal with binary files when checking out a sandbox against a
> repository_ For examples, images that belongs to the project, binary logs,
> etc. that are inside the sandbox as a part of ther project

Just make sure they get cvs-added as binary files.  With TortoiseCVS,
this means having a good CVSROOT/cvswrappers file on the server.


-- 
pa at panix dot com
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs checkout date

[Larry Jones]

[EMAIL PROTECTED] writes:
> 
>   I would like my application to print, when executed, the date
> when the source from which it was built was retrieved from the cvs tree.

See the manual:



-Larry Jones

If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Trigger for CruiseControl Configuration

[Buorn, Yoway]

In case anyone is interested, I discovered that STDIN, STDOUT, and
STDERR are all capable of blocking a CVS commit.  My solution was to
redirect all three away to either a log or /dev/null.  This completely
dissociates the process from the parent shell and therefore allows the
loginfo script to run asynchronously, and therefore complete your commit
a lot more quickly.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Buorn, Yoway
Sent: Tuesday, May 24, 2005 7:15 PM
To: info-cvs@gnu.org
Subject: RE: CVS Trigger for CruiseControl Configuration

I tried placing the entire rsh line in parentheses and following it with
the '&', but I'm getting the same result.  Although I don't have that
BUGS section in my man page, the -n option is listed, but it doesn't
seem to behave as expected.  When I specify -n, I always get output to
stdout.  I might shoot this question over to some scripting mailing
lists.  Thanks for all your help. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Todd Denniston
Sent: Tuesday, May 24, 2005 2:56 PM
To: Buorn, Yoway
Subject: Re: CVS Trigger for CruiseControl Configuration

"Buorn, Yoway" wrote:
> 
> Good call on removing eval.  I originally mistakenly assumed that eval

> was necessary to get ${REMCMD} expanded on the local machine 
> (${REMCMD} would be meaningless on the remote machine), but all I had 
> to do was remove the single quotes from ${REMCMD}.  Now my script is a

> bit cleaner, however, CVS commit is still waiting for Maven to 
> complete.  I now have the '&' after the rsh line (without eval).

just checked a local script we have ... I think may be the remote
command is eating the &.
you might try
rsh -l cruise -n db2.rd.ideas.gd-ais.com \"${REMCMD}\" & or (rsh -l
cruise -n db2.rd.ideas.gd-ais.com ${REMCMD} ) &


> 
> There isn't any BUGS section in the rsh man page (Solaris 8).  Any 
> further suggestions would be appreciated.
the BUGS section I have:
 If you are using csh(1) and put a rsh in the background without
redirect-
 ing its input away from the terminal, it will block even if no
reads are
 posted by the remote command.  If no input is desired you should
redirect
 the input of rsh to /dev/null using the -n option.

BTW: probably better to stay on the list, there are others out there who
may the answers better than I.

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the
Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: CVS Trigger for CruiseControl Configuration

[Buorn, Yoway]

I tried placing the entire rsh line in parentheses and following it with
the '&', but I'm getting the same result.  Although I don't have that
BUGS section in my man page, the -n option is listed, but it doesn't
seem to behave as expected.  When I specify -n, I always get output to
stdout.  I might shoot this question over to some scripting mailing
lists.  Thanks for all your help. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Todd Denniston
Sent: Tuesday, May 24, 2005 2:56 PM
To: Buorn, Yoway
Subject: Re: CVS Trigger for CruiseControl Configuration

"Buorn, Yoway" wrote:
> 
> Good call on removing eval.  I originally mistakenly assumed that eval

> was necessary to get ${REMCMD} expanded on the local machine 
> (${REMCMD} would be meaningless on the remote machine), but all I had 
> to do was remove the single quotes from ${REMCMD}.  Now my script is a

> bit cleaner, however, CVS commit is still waiting for Maven to 
> complete.  I now have the '&' after the rsh line (without eval).

just checked a local script we have ... I think may be the remote
command is eating the &.
you might try
rsh -l cruise -n db2.rd.ideas.gd-ais.com \"${REMCMD}\" & or (rsh -l
cruise -n db2.rd.ideas.gd-ais.com ${REMCMD} ) &


> 
> There isn't any BUGS section in the rsh man page (Solaris 8).  Any
> further suggestions would be appreciated.
the BUGS section I have:
 If you are using csh(1) and put a rsh in the background without
redirect-
 ing its input away from the terminal, it will block even if no
reads
are
 posted by the remote command.  If no input is desired you should
redirect
 the input of rsh to /dev/null using the -n option.

BTW: probably better to stay on the list, there are others out there who
may
the answers better than I.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Re: CVS INSTALLATION ON LINUX RHEL AS 2.1 OR 3 - FOR IBM WSAD 5.1.2 VERS

[edoardo bianco]

thanks Ankush Grover

i try to read the documentation u suggest

edoardo


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: cvs verifying log message format per branch

[Matt Doar]

I've attached a Perl script that I wrote to require bug ids in commit
messages on a per-branch basis. Its core is derived from cvs_acls, and
it should be installed in a similar way. No guarantees, and you should
have someone who knows Perl better than I do read it and check it very
carefully before using it.

Server version: cvs 1.12.9

~Matt 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> On Behalf Of vik
> Sent: Tuesday, May 24, 2005 10:20 AM
> To: info-cvs@gnu.org
> Subject: Re: cvs verifying log message format per branch
> 
> Thanks for your quick replies! I dont know perl myself,but am going to
> ask a co-worked to help out. Say my production branch is called
> 'production-release-1-1',  so one way is to checkout verifymsg from
> CVSROOT and then modify it to use
> 
> cvs -qn status | grep '^ 'production-release-1-1' |.
> 
> I did read about the cvs_acls script and am assuming its available in
> the CVSROOT directory by default? I would surely prefer to use it if
> its been tested and used before, given my zero knowledge of
> Perl/scripting tool.
> 
> Thanks again!
> 
> Vik
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 


require_bugid
Description: require_bugid
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Trigger for CruiseControl Configuration

[Todd Denniston]

> "Buorn, Yoway" wrote:
> 
> I am attempting to use a CVS trigger (loginfo) to asyncrhonously execute a
> script that runs "maven cruisecontrol" to reconfigure CruiseControl on
> each commit. The intent is to capture new CVS modules and automatically
> configure them for continuous integration. (even though I only want this
> upon adding of a module, I decided reconfiguration on every commit is not
> too bad of a side effect)
> 
> I have a build machine (running CruiseControl) and a CVS machine.  There
> is an entry in loginfo to execute a script on the CVS machine that uses
> rsh to execute commands on the build machine (to reconfigure
> CruiseControl).  This is what it looks like:
> 
> CVS Machine
> 
> /export/CVS/CVSROOT/loginfo
> 
> DEFAULT \
>(/import/home/yoway/bin/rsh-cvs-cruise.sh %s) >> \
> /import/home/yoway/commitlog &
> 
> /import/home/yoway/bin/rsh-cvs-cruise.sh
> 
> REMCMD="'bin/cvs-cruise.sh "${1}"'"
> echo ${REMCMD}
> eval rsh -l cruise -n db2.rd.ideas.gd-ais.com ${REMCMD}
> 
 
> So my problem is this does not run asynchronously.  No matter where I put
> the '&', the commit always blocks until maven is done.  I've tried placing
> the '&' in rsh-cvs-cruise.sh after the last line (the eval line) and it
> still blocks.  I've tried placing the '&' after "maven cruisecontrol" in
> cvs-cruise.sh and it still blocks.
> 

1) any reason you use 'eval' instead of just calling the command? 
2) have you tried putting the '&' at the end of the rsh? i.e.,
replace `eval rsh -l cruise -n db2.rd.ideas.gd-ais.com ${REMCMD}`
with `rsh -l cruise -n db2.rd.ideas.gd-ais.com ${REMCMD} &`
which should put the rsh in the background.
3) have you noted the BUGS section of the rsh man page (at least its there
on Fedora Core 2)?


This is not intended to be direction to a gov contractor to do anything,
just a listing of information which _may_ answer the question which was
asked, and questions that may lead to answers for the question which was
asked.
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the WarfighterThe opinions expressed here are not sanctioned by and do not necessarily 
represent those of my employer.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs verifying log message format per branch

[vik]

Thanks for your quick replies! I dont know perl myself,but am going to
ask a co-worked to help out. Say my production branch is called
'production-release-1-1',  so one way is to checkout verifymsg from
CVSROOT and then modify it to use

cvs -qn status | grep '^ 'production-release-1-1' |.

I did read about the cvs_acls script and am assuming its available in
the CVSROOT directory by default? I would surely prefer to use it if
its been tested and used before, given my zero knowledge of
Perl/scripting tool.

Thanks again!

Vik

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs verifying log message format per branch

[Todd Denniston]

"Mark D. Baushke" wrote:
> 
> 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:
> > " in our production release branch, but not in the main branch.
> > Here's what i found in the other post i read:

> 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.
> 
Would Vik be able to use the same routines as cvs_acls (a commitinfo script,
that comes with the cvs source code) uses, or is the branch passed into the
commitinfo script?
It sounds like Vik wants a 'verifymsg_acls' in the end anyway, may as well
start with code that has already had some serious debugging for a similar
purpose.
 
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs verifying log message format per branch

[Mark D. Baushke]

-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:
> " 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: CVS INSTALLATION ON LINUX RHEL AS 2.1 OR 3 - FOR IBM WSAD 5.1.2 VERSION MANAGEMENT CODE

[ankush grover]

On 5/21/05, edoardo bianco <[EMAIL PROTECTED]> wrote:
> Hi,
>  i need to install CVS on the Red-hat linux EL AS 2.1 or 3.0. I'll
> use CVS for version management on IBM WSAD 5.1.2 development
> environment. Anyone could suggest a step by step guide to install CVS
> and 

I did configuring of cvs on Fedora Core 3 which is a Red Hat Product.
These links are good for configuring CVS on Red Hat Linux .

https://ccvs.cvshome.org/fom/cache/124.html

http://www.freeos.com/articles/4608/

Moreover what protocol your going to use is also a case.The above
links guide you for simple configuration of cvs for pserver .For using
protocols like ssh you have to make further changes.

migration of an already exist CVS repository on the Red-hat linux
 7.2 to this new installation?

Sorry I don't know the procedure of migrating the Repository from the
earlier to the new installation.

Moreover you can refer to the cvs documentation available at

www.cvshome.org.


Regards

Ankush Grover


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS update -j failes to merge

[Asbjørn Sæbø]

On Wed, May 18, 2005 at 12:53:03PM -0400, Jim Hyslop wrote:
> Asbjørn Sæbø wrote:
> >On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote:
> >>What version of client and server are you using?
> >
> >
> >Both are 1.12.9 
> 
> Hmmm... I just tried it with 1.12.12, and it worked OK. Can you upgrade 
> to the latest versions and try again?

Now I have tested again, on clean checkouts, with both 1.12.9 and
1.12.12. The results seem to indicate a difference between these two
versions.  With 1.12.12, the expected merging takes place, with 1.12.9
it does not.

Actually, it seems that what makes the difference is whether the client 
is 1.12.12 or not (see below).  When the client is 1.12.12, the merging 
I am expecting takes place.  When the client is 1.12.9, it does not.

(It should be mentioned that I am not totally certain that my repository
is sound.  I installed cvs the normal way ("apt-get install" on a
Debian-based box).  But the actual ldas module is just copied to this
server from another one.  It seems to work, but I am not sure whether
this is the formally correct way to transfer a module to another
server.)


Procedure:
--
rm -rf ldas
cvs co ldas
cvs update -j dev_20050413_b ldas

The output from the "update -j" command is shown below.  (The output is 
truncated for the cases where merging took place.)



Case 1:
---
client: cvs 1.12.9
server: 1.12.9

[EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas
cvs update: Updating ldas
cvs update: Updating ldas/doc
cvs update: Updating ldas/doc/doxygen
cvs update: Updating ldas/doc/ldasdoc
cvs update: Updating ldas/doc/ldasdoc/developer
cvs update: Updating ldas/doc/ldasdoc/reference
cvs update: Updating ldas/doc/ldasdoc/spec
cvs update: Updating ldas/doc/ldasdoc/usermanual
cvs update: Updating ldas/extracode
cvs update: Updating ldas/orig_src
cvs update: Updating ldas/src
cvs update: Updating ldas/testcode
[EMAIL PROTECTED]:~/tmp/tmp$  


Case 2:
---
client: cvs 1.12.12
server: 1.12.12

[EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas
cvs update: Updating ldas
RCS file: /local/cvs/ldas/Tags,v
retrieving revision 1.17
retrieving revision 1.17.2.2
Merging differences between 1.17 and 1.17.2.2 into Tags
rcsmerge: warning: conflicts during merge
cvs update: Updating ldas/doc
[...]
cvs update: Updating ldas/doc/ldasdoc/reference
cvs update: Updating ldas/doc/ldasdoc/spec
RCS file: /local/cvs/ldas/doc/ldasdoc/spec/specification.tex,v
retrieving revision 1.6
retrieving revision 1.6.4.1
Merging differences between 1.6 and 1.6.4.1 into specification.tex
ldas/doc/ldasdoc/spec/specification.tex already contains the differences 
between 1.6 and 1.6.4.1
[More merging]


Case 3:
---
Client: 1.12.12
Server: 1.12.9

[EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas
cvs update: Updating ldas
RCS file: /local/cvs/ldas/Tags,v
retrieving revision 1.17
retrieving revision 1.17.2.2
Merging differences between 1.17 and 1.17.2.2 into Tags
rcsmerge: warning: conflicts during merge
cvs update: Updating ldas/doc
[...]
cvs update: Updating ldas/doc/ldasdoc/spec
RCS file: /local/cvs/ldas/doc/ldasdoc/spec/specification.tex,v
retrieving revision 1.6
retrieving revision 1.6.4.1
Merging differences between 1.6 and 1.6.4.1 into specification.tex
ldas/doc/ldasdoc/spec/specification.tex already contains the differences 
between 1.6 and 1.6.4.1
[More merging]


Case 4:
---
Client: 1.12.9
Server: 1.12.12

[EMAIL PROTECTED]:~/tmp/tmp$ cvs update -j dev_20050413_b ldas
cvs update: Updating ldas
cvs update: Updating ldas/doc
cvs update: Updating ldas/doc/doxygen
cvs update: Updating ldas/doc/ldasdoc
cvs update: Updating ldas/doc/ldasdoc/developer
cvs update: Updating ldas/doc/ldasdoc/reference
cvs update: Updating ldas/doc/ldasdoc/spec
cvs update: Updating ldas/doc/ldasdoc/usermanual
cvs update: Updating ldas/extracode
cvs update: Updating ldas/orig_src
cvs update: Updating ldas/src
cvs update: Updating ldas/testcode
[EMAIL PROTECTED]:~/tmp/tmp$ 



Asbjørn





___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS update -j failes to merge

[Jim Hyslop]

Asbjørn Sæbø wrote:
On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote:
What version of client and server are you using?

Both are 1.12.9 
Hmmm... I just tried it with 1.12.12, and it worked OK. Can you upgrade 
to the latest versions and try again?

--
Jim

___
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?

[Mark D. Baushke]

-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: CVS update -j failes to merge

[Asbjørn Sæbø]

On Fri, May 13, 2005 at 03:58:12PM -0400, Jim Hyslop wrote:
> Asbjørn Sæbø wrote:
> >On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote:

[Updating/merging did not work from outside the module/directory, but
worked from inside the directory. ]

> >>[EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas
[Did not merge]

> >[EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b .
[Worked, did merge]


> >[Much retrieving and merging] 
> > 
> >Is this difference between naming the module/directory and standing in 
> >the module/directory expected behaviour?

> No. I just tried it with cvs 1.11.20, and it worked OK: 
> 
> [...] 
> What version of client and server are you using?

Both are 1.12.9 

Asbjørn



___
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

[Todd Denniston]

S I wrote:
> 
> Hi
> 
> Is there any way to force the users to comment or annotate their commits or
> checkins?
> 

Short answer, Yes.

> 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?

Short answer, Yes.

Long answer, search the list and read the manual, specifically on commitinfo
and verifymsg.

I have sent a few messages[1] over the years to the list on how I have done
it, perhaps they would be of use to you, specifically[2] and [3]

[1]
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=denniston+verifymsg&submit=Search%21&idxname=info-cvs&max=20&result=normal&sort=score


[2] "Re: using commitinfo and verifymsg" 
 Date: Thu, 24 Jun 2004 10:50:22 -0500
http://lists.gnu.org/archive/html/info-cvs/2004-06/msg00414.html

[3] "Re: Verifymsg on branches?"Date: Wed, 22 Nov 2000 15:29:54
http://lists.gnu.org/archive/html/info-cvs/2000-11/msg00330.html
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter


___
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

[Mark D. Baushke]

-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: CVS Annotate or FORCING users to comment their checkins

[Mark E. Hamilton]

S I wrote:
Hi
Is there any way to force the users to comment or annotate their commits 
or checkins?

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?
You can use the verifymsg administrative file to validate the log 
message prior to commits.


--

Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
505-844-7666

___
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?

[Bulgrien, Kevin]

http://lists.gnu.org/archive/html/info-cvs/2004-12/msg00074.html

Raises confidence that nothing bad happens, and, since CVS has been
updated since the repository was created, implies that it should
have been done anyway.

> From:  Larry Jones 
> Subject:  Re: Some questions on CVS upgrade 
> Date:  Tue, 7 Dec 2004 17:35:20 -0500 (EST)
 
...

> It's also a good idea to run ``cvs init'' on your repository after
> upgrading to create any new administrative files (it will carefully
> preserve your existing ones) and make any other necessary changes to
> your repository should there be any in the future (there have never
> been any so far).

...

>> 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?
>> 
>> 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.
 
Kevin R. Bulgrien
Product Engineer
 
General Dynamics C4 Systemshttp://www.tripointglobal.com/
VertexRSI
1915 Harrison Road Tel: 903-295-1480 x288
Longview, TX 75604-5438Fax: 903-295-1479 


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS update -j failes to merge

[Jim Hyslop]

Asbjørn Sæbø wrote:
On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote:
I have a CVS module (named "ldas") where I would like to merge the
contents of a branch into the trunk.  According to the documentation,
is seems that I should be able to du this using "cvs update -j
".  However, this does not work.  No merging takes place,
the files on the trunk do not receive the changes from the branch.
[...]
[EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas

However, when I changed into the ldas directory, and did the update,
it worked:
[EMAIL PROTECTED]:~/ldas/utvikling$ cd ldas
[EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b .
[Much retrieving and merging]
Is this difference between naming the module/directory and standing in
the module/directory expected behaviour?
No. I just tried it with cvs 1.11.20, and it worked OK:
C:\cvs-test\jim>cvs -d \cvs_repository tag -r brach_base -b abranch
cvs tag: Tagging .
T test.txt
C:\cvs-test\jim>cvs up -r abranch
cvs update: Updating .
C:\cvs-test\jim>echo branch changes>>test.txt
C:\cvs-test\jim>cvs ci -m "branch changes" test.txt
Checking in test.txt;
\cvs_repository/cvs-test/jim/test.txt,v  <--  test.txt
new revision: 1.2.2.1; previous revision: 1.2
done
C:\cvs-test>cvs up -A jim
cvs update: Updating jim
U jim/test.txt
C:\cvs-test>cvs up -j abranch jim
cvs update: Updating jim
RCS file: \cvs_repository/cvs-test/jim/test.txt,v
retrieving revision 1.2
retrieving revision 1.2.2.1
Merging differences between 1.2 and 1.2.2.1 into test.txt
What version of client and server are you using?
--
Jim

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS update -j failes to merge

[Asbjørn Sæbø]

On Fri, May 13, 2005 at 10:04:59AM +0200, Asbjørn Sæbø wrote:
> I have a CVS module (named "ldas") where I would like to merge the
> contents of a branch into the trunk.  According to the documentation,
> is seems that I should be able to du this using "cvs update -j
> ".  However, this does not work.  No merging takes place,
> the files on the trunk do not receive the changes from the branch.
> [...]
> [EMAIL PROTECTED]:~/ldas/utvikling$ cvs update -j dev_20050413_b ldas

However, when I changed into the ldas directory, and did the update,
it worked:

[EMAIL PROTECTED]:~/ldas/utvikling$ cd ldas
[EMAIL PROTECTED]:~/ldas/utvikling/ldas$ cvs update -j dev_20050413_b .
[Much retrieving and merging]

Is this difference between naming the module/directory and standing in
the module/directory expected behaviour?

Asbjørn
-- 
Asbjørn Sæbø, post.doc. 
Centre for Quantifiable Quality of Service in Communication Systems
Norwegian University of Science and Technology
http://www.q2s.ntnu.no/ >


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS and Images

[Jim Hyslop]

Mychael Scribner wrote:
I have a simply little question. I do a lot of web based project that often
have images. Is their and do's or don'ts that I be watching for with images.
Should I not include them when I import a project?
There's no reason to exclude them. Just make sure you mark them as 
binary when you add them - either add the extensions to 
$CVSROOT/CVSROOT/cvswrappers, or explicitly use the '-kb' option with 
the 'cvs add' command.

--
Jim

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS migration question

[Jim Hyslop]

[EMAIL PROTECTED] wrote:
I've been thinking about this since reading it on CM Crossroads this 
morning.  I don't think it would be too terribly complicated.  On the 
server side, I think it's just a matter of packing up the entire 
repository and ftp'ing it to the new server (or just copying it if you 
have a samba share).
That's the bulk of it. You would have to update (or more likely rewrite) 
any scripts, such as commitinfo, loginfo, etc.

My only concern is whether or not you'd have to 
worry about the "^M" end-of-line problem between windows and Unix.
Nope. RCS file format always uses a plain ASCII LF character as the line 
terminator, regardless of the platform the RCS file lives on. It's the 
client that translates LF into the appropriate line terminator for the 
client platform.

--
Jim

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS migration question

[dzielke]

You must be Dusty on CM Crossroads then? ;-)

I've been thinking about this since reading it on CM Crossroads this morning.  I don't think it would be too terribly complicated.  On the server side, I think it's just a matter of packing up the entire repository and ftp'ing it to the new server (or just copying it if you have a samba share).  My only concern is whether or not you'd have to worry about the "^M" end-of-line problem between windows and Unix.  I haven't had time to go play with that yet to see if it would be an issue.  If it's not, you'd just have to make the appropriate changes to the configuration files once it's on the new server. 

On the user's client side, all users would have to do a cvs release on their local sandboxes, and then change their CVSROOT variables to reference the name of the new server.

Thanks,
Don Zielke
American Electric Power
Direct (614) 583-6337
Audinet 8-220-6337
Email dzielke (at) aep.com
---
KForce Professional Staffing
501 W. Schrock Road Suite 207
Westerville, OH 43081






"Raghunath, Santhosh" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/12/2005 10:28 AM

        
        To:        "'info-cvs@gnu.org'" 
        cc:        
        Subject:        CVS migration question


I would like to know the procedure/steps to follow to do a migration of a project under the CVS repository on a Windows XP box to a CVS repository under Linux.  The CVS versions are same on both the boxes.  I would like to retain all the version history and log information during the migration.
 
Thanks
~Santhosh
 
Santhosh Raghunath
Tel: 781-348-8464
 
 

This electronic message transmission contains information from the Company that may be proprietary, confidential and/or privileged.
The information is intended only for the use of the individual(s) or entity named above.  If you are not the intended recipient, be
aware that any disclosure, copying or distribution or use of the contents of this information is prohibited.  If you have received
this electronic transmission in error, please notify the sender immediately by replying to the address listed in the "From:" field.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs and ldap

[Larry Jones]

liz writes:
> 
> I am exporting the CVSROOT variable.  I suspect I am doing it
> correctly. Is there any way to tell what is going wrong during the
> authentication process?  I haven't the foggiest idea where to look.

If your syslog has an AUTHPRIV facility (check the man page), CVS logs
more detailed information about authentication to it.

-Larry Jones

Mom would be a lot more fun if she was a little more gullible. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: 'cvs status' returns error if I delete a directory in my local working copy

[Russ Sherk]

On 4/22/05, Todd Foster <[EMAIL PROTECTED]> wrote:
> We have a top-level script that does several cvs checkouts from multiple
> repositories to create a local working copy for the end-user (basically
> brings in source code from several projects in order to compile correctly).
> For discussion purposes, let's say the result of two 'cvs checkout' commands
> is the following directory structure.
> 
>   .
>   |- Dir1: Dir1 comes from Repository1
>   `- tools  : tools/ comes from Repository1 (with no files within
> tools/)
>   |- Dir2: Dir2 comes from Repository1
>   `- Dir3   : Dir3 comes from Repository2
Um... how did you arive at this directory structure?  (what are the
exact cvs commands used to check out?)

If you are doing some sort of copy operation, then it is possible that
(if the checked out Dir3 is copied last) that the CVS dir is
overwritten (by repository2's checkout info) thus there will be no
record of Dir2.

--Russ
> 
> Note: the 'cvs checkout' for Repository 1 (creating Dir1, tools/ and
> tools/Dir2)  is done first initially creating the local working copy and
> Repository 2 is always second (creating Dir3).
> 
> If for some reason, Dir3 is deleted, then cvs status returns an error
> message:
> 
> cvs status: Examining Dir3
> cvs [status aborted]: could not chdir to Dir3: No such file or directory
> 
> If I delete the line in CVS/Entries within tools/ for Dir3 (D/Dir3), the
> 'cvs status' begins working again.
> 
> The oddity, is that if I delete tools/Dir2 (instead of Dir3), then 'cvs
> status' completes with no errors.  For this case, there still exists an
> entry in the tools/CVS/Entries file for Dir2 (D/Dir3).
> 
> Is this expected behavior?  I'm asking because there are some
> inconsistencies in the 'cvs status' behavior.
> 
> Thanks,
> 
> Todd
> 
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs
>


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: 'cvs status' returns error if I delete a directory in my local working copy

[Spiro Trikaliotis]

Hello,

* On Sat, Apr 23, 2005 at 02:38:08AM + Todd Foster wrote:
 
> If for some reason, Dir3 is deleted, then cvs status returns an error
> message:

How do you delete it? I hope, you are using "cvs release -d"?

> Is this expected behavior?  I'm asking because there are some
> inconsistencies in the 'cvs status' behavior.

I don't think that this is expected behaviour, either, as it is
inconsistent. Anyway, it is always better to remove a directory by
running "cvs release -d" instead of deleting it directory. I believe
your odd behaviour will be gone with this.

HTH,
   Spiro.

-- 
Spiro R. Trikaliotis  http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs add-ing large source tree

[Larry Jones]

Jate Sujjavanich writes:
> 
> I am having trouble "cvs add"-ing a very large source tree (500mb). I
> take the following steps:

It's much simpler to just import it.

-Larry Jones

I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Problem

[Manuel Ledesma]

Mark D. Baushke wrote:
-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-
 

Thanks everybody, I solved the problem by adding my machine to 
hosts.allow, thanks by brinthig this out.

This two command help to find the problem :
ps ax |grep xinetd |grep -v grep |awk "{print $1}"
strace -f -o /tmp/zzz -p [pid - tooked from previos command]
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Problem

[Mark D. Baushke]

-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: CVS Problem

[Mike Klinke]

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.


Regards, Mike Klinke


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Problem

[Mark D. Baushke]

-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

[Manuel Ledesma]

Mark D. Baushke wrote:
-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-
 

I really don't know what can be the cause? I changed my cvspserver file 
to yours.

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
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs