mh->hr: do you have a reference for the "old lock_dir" problem. I'm not able to
find it. Also, do you have an idea on how to reproduce this problem ?

With old lock_dir problem I mean that I've seen it before on several versions of
CVS servers (but not on OpenOffice.org). It's hard to reproduce and it's
transient, that is the problem tends to vanish after a while. I don't have a CVS
bugid at hand, currently.

quote from ooo ML:
"the bug is definitely connected to using the -r<tag> switch of the checkout
command. I've seen it several times now on several versions of CVS servers. It's
connected with the lockdir feature of CVS. It won't happen if lockdir in
CVSROOT/config is disabled. Sometimes a cleanup of the lockdir directory works,
sometimes not. I don't know. The code in lock.c of the CVS sources is not
exactly nice but I can't make out a obvious problem. "

change old title from "Some user can't checkout a module with specified branch
tag" to "CVSROOT/valtags have not been upgraded properly"

cvs server aborts co of a branch, because old val-tags have not been upgraded.
please add content of old val-tags to new one on production server.

Accepting issue to see if we can have this quickly updated.

Eric

I'm retagging a test file with know tags, so most tags should be now back again
in the val-tags.

i created pcn 24593 to address this issue.
Eric

arrgh, pluby is not able to comment this issue, so I paste his comments here:
"Martin,

For some reason, IssueZilla will not allow me to post a comment to bug 23306 so
I am sending my comment directly to you as Iit might be helpful:

This may not help, but I have found a way to check out a tag using anoncvs using
the following steps. These steps may be useful for debugging where the problem is.

To check out a tag without the error, do the following:

1. Checkout the tip of the tree for a module using the following command:

cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs <module>

2. Update the checked out module to the desired tag using the following command:

cd <module> ; cvs update -r <tag>

3. Delete the module using the following command:

rm -Rf <module>

After the above, you can perform a clean checkout of the module using the tag
using the following command:

cvs -d :pserver:anoncvs@anoncvs.services.openoffice.org:/cvs -r <tag> <module>

One interesting thing to note is that I need to repeat these steps if more than
a day passes since my last checkout. This leads me to conclude that some file is
getting recorrupted periodically.

Patrick"

Internal task 24593 has been filed for this defect- I'll update this issue when
the internal issue has been updated

hi, kenneths, This issue is rather urgent, despite its being only a p2.  Can you update by today's 
end?
thanks
louis

Louis: I checked with the engineers about this issue. They're currently working
on another cvs related problem and will turn their attention to this issue when
they've completed working on the other one. They're quasi-related so I expect a
more substantial update by Monday and will update this issue then.

*** Issue 23248 has been marked as a duplicate of this issue. ***

CC me, as I get more and more user complaints about this.

Martin, Heiner, Rüdiger,
wouldn't it be feasible to tag the testfile with all known tags?
I could provide a list of all pre-SC26 tags.

mh->st: this was already the first action I did if I recognized this problem.
mysteriously old tags seems to disappear after a while (see patricks comment) so
this is not a solution for longer term. I'm wondering if there's a limitation of
number of tags in the val-tags file and if we might use to many tags in the
meantime. please see /var/tmp/val-* for backups of ftp.

update:
CollabNet has worked on a script that should resolve this and will be run later today or tomorrow. 
More updates tomorrow.  
best,
Louis 

Louis - do you have any information on the script?

Louis: according to internal issue 24753, the script was run on 12/18 and was
successful

Well it still seems to be a problem.

Today from anoncvs I did :

cvs -z3 co -rcws_srx645_ooo111fix2 OpenOffice

and got the same errors. Throwing away my existing source tree and doing a 
clean checkout didn't help.

mh->terryt: the correct tag is cws_fix645_ooo111fix2.

Thanks Martin - it must have been a silly copy/paste problem on my part. Sorry 
for the noise.

closing
the script was run on 12/18 and was successful

close issue.

the CVSROOT/val-tags is quite empty again, so the difficulties for OOo
developers to check out their branches are back again.

Working on this now.  Investigating the valtags problem and attempting to have 
it repopulated.

The script is running now, should take about an hour to run.

The tags should be available again, please test and reply.

I tested with a tag in the api project (XD2) and it worked.

reopened again, most tags lost again

This is working now, I tested it successfully.  Please confirm.

Closing as fixed.

Closing this issue.

reopened again, most tags lost again

This is stopping me working - I can't resync either of my cws' since none of the
cwstools work for me;
Essentially this command:

cvs checkout -r cws_src680_buildcond02 config_office

doesn't work, and neither does

cvs checkout -r cws_src680_qpro01 filter

This is acutely irritating. I get the lock.c:222 assertions as below.

Accepting this issue. 

Internal team running scripts to resolve this. reducing this to P2

This should now be done. Please verify and close.

The val-tags file seems to contain all valid tags again.
Feel free to mark issues as resolved/fixed if you consider them solved.

Closing the issue as per comments of st.

Jobin.

Trying to checkout connectivity:

michael@linux:/tmp/resync> /usr/bin/cvs -d ':pserver:mmeeks@localhost:/cvs'
checkout -rcws_src680_evoab201 connectivity
lock.c:222: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'
cvs [server aborted]: received abort signal
cvs [server aborted]: received abort signal
lock.c:222: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'

A checkout / update to that tag works fine. The tag is clearly there  in the files.

I wouldn't mind, but it makes it impossible for me to commit some changes for
review before Frank leaves for a 3 week holiday which is acutely annoying.

Support, val-tags lost ~70% of the tags. Please run the script again.

Accepting. Internal request created.

The script has been run. Resolving.

many tags are lost again.

*** Issue 57818 has been marked as a duplicate of this issue. ***

*** Issue 57817 has been marked as a duplicate of this issue. ***

Hi,

We apologize for the delayed response in this. Can you please let us know
whether this issue still exists. Based on which we can go ahead and run the
script again.

Thanks,
Jeeva - Support Operations

Jeeva,

this issue pops up once in a while; it has probably has something to do with the
process which updates the val-tags file. Currently we have no problems, but it
can happen again if there has been no change done to the process.

Heiner

Jeeva,

this issue pops up once in a while; it has probably something to do with the
process which updates the val-tags file. Currently we have no problems, but it
can happen again if there has been no change done to the process.

Heiner

Correct; we still need to run the script when this occurs. Closing this for 
now. You can either re-open it or open another new issue.

close issue.