Issue 23306 - CVSROOT/val-tags have not been upgraded properly
CVSROOT/val-tags have not been upgraded properly
Status: CLOSED FIXED
Product: Infrastructure
Classification: Infrastructure
Component: _openoffice.org CVS (obsolete)
current
All All
: P2 trivial with 1 vote (vote)
: ---
Assigned To: Unknown
issues@www
:
: 23248 57817 57818 (view as issue list)
Depends on:
Blocks: 23231
  Show dependency treegraph
 
Reported: 2003-12-08 13:00 UTC by jens-heiner.rechtien
Modified: 2007-02-14 23:30 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description jens-heiner.rechtien 2003-12-08 13:00:33 UTC
User hjs tried to checkout a module with the following command:

jds-1 so-ret1/SRX645> cvs -d :pserver:hjs@so-cvs-tunnel:/cvs co -rmws_srx645
i18n_simple

and got the following error message

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'
cvs checkout: dying gasps from so-cvs-tunnel unexpected

jds-1 so-ret1/SRX645> cvs -d :pserver:hjs@so-cvs-tunnel:/cvs co -rmws_srx645
i18n_simple
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'
cvs checkout: dying gasps from so-cvs-tunnel unexpected

For me it's looks like the old "lock_dir" problem in the CVS server.
Comment 1 Martin Hollmichel 2003-12-08 15:58:04 UTC
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 ?
Comment 2 jens-heiner.rechtien 2003-12-08 16:38:47 UTC
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.
Comment 3 Martin Hollmichel 2003-12-08 18:20:50 UTC
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. "
Comment 4 Martin Hollmichel 2003-12-08 23:23:09 UTC
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.
Comment 5 Unknown 2003-12-08 23:33:18 UTC
Accepting issue to see if we can have this quickly updated.

Eric
Comment 6 Martin Hollmichel 2003-12-08 23:40:11 UTC
I'm retagging a test file with know tags, so most tags should be now back again
in the val-tags.
Comment 7 Unknown 2003-12-08 23:55:25 UTC
i created pcn 24593 to address this issue.
Eric
Comment 8 Martin Hollmichel 2003-12-10 14:11:07 UTC
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"
Comment 9 Unknown 2003-12-10 17:32:30 UTC
Internal task 24593 has been filed for this defect- I'll update this issue when
the internal issue has been updated
Comment 10 lsuarezpotts 2003-12-12 20:00:44 UTC
hi, kenneths, This issue is rather urgent, despite its being only a p2.  Can you update by today's 
end?
thanks
louis
Comment 11 Unknown 2003-12-12 22:25:32 UTC
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.
Comment 12 stx123 2003-12-14 17:01:48 UTC
*** Issue 23248 has been marked as a duplicate of this issue. ***
Comment 13 rt 2003-12-17 08:48:28 UTC
CC me, as I get more and more user complaints about this.
Comment 14 stx123 2003-12-17 09:01:14 UTC
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.
Comment 15 Martin Hollmichel 2003-12-17 12:38:33 UTC
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.
Comment 16 lsuarezpotts 2003-12-17 22:34:21 UTC
update:
CollabNet has worked on a script that should resolve this and will be run later today or tomorrow. 
More updates tomorrow.  
best,
Louis 
Comment 17 Unknown 2004-01-13 16:36:15 UTC
Louis - do you have any information on the script?
Comment 18 Unknown 2004-01-13 16:42:28 UTC
Louis: according to internal issue 24753, the script was run on 12/18 and was
successful
Comment 19 terryt 2004-01-17 01:46:38 UTC
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.
Comment 20 Martin Hollmichel 2004-01-19 09:57:22 UTC
mh->terryt: the correct tag is cws_fix645_ooo111fix2.
Comment 21 terryt 2004-01-20 10:16:13 UTC
Thanks Martin - it must have been a silly copy/paste problem on my part. Sorry 
for the noise.
Comment 22 Unknown 2004-01-20 17:35:56 UTC
closing
the script was run on 12/18 and was successful
Comment 23 Martin Hollmichel 2004-05-24 12:44:57 UTC
close issue.
Comment 24 Martin Hollmichel 2004-07-01 11:57:29 UTC
the CVSROOT/val-tags is quite empty again, so the difficulties for OOo
developers to check out their branches are back again.
Comment 25 Unknown 2004-07-01 17:31:18 UTC
Working on this now.  Investigating the valtags problem and attempting to have 
it repopulated.
Comment 26 Unknown 2004-07-01 18:57:31 UTC
The script is running now, should take about an hour to run.
Comment 27 Unknown 2004-07-01 21:58:45 UTC
The tags should be available again, please test and reply.
Comment 28 Unknown 2004-07-01 23:14:21 UTC
I tested with a tag in the api project (XD2) and it worked.
Comment 29 Martin Hollmichel 2004-07-29 16:11:48 UTC
reopened again, most tags lost again
Comment 30 Unknown 2004-07-29 18:20:54 UTC
This is working now, I tested it successfully.  Please confirm.
Comment 31 Unknown 2004-08-04 19:37:46 UTC
Closing as fixed.
Comment 32 Unknown 2004-08-31 18:41:54 UTC
Closing this issue.
Comment 33 Martin Hollmichel 2005-01-27 17:41:37 UTC
reopened again, most tags lost again
Comment 34 mmeeks 2005-01-28 12:27:02 UTC
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.
Comment 35 Unknown 2005-01-28 18:07:42 UTC
Accepting this issue. 
Comment 36 Unknown 2005-01-28 18:59:11 UTC
Internal team running scripts to resolve this. reducing this to P2
Comment 37 Unknown 2005-01-28 20:49:54 UTC
This should now be done. Please verify and close.
Comment 38 stx123 2005-02-01 14:29:02 UTC
The val-tags file seems to contain all valid tags again.
Feel free to mark issues as resolved/fixed if you consider them solved.
Comment 39 Unknown 2005-02-04 06:45:56 UTC
Closing the issue as per comments of st.

Jobin.
Comment 40 mmeeks 2005-04-15 16:04:48 UTC
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.
Comment 41 stx123 2005-04-15 16:21:04 UTC
Support, val-tags lost ~70% of the tags. Please run the script again.
Comment 42 Unknown 2005-04-15 18:27:06 UTC
Accepting. Internal request created.
Comment 43 Unknown 2005-04-15 22:13:14 UTC
The script has been run. Resolving.
Comment 44 Martin Hollmichel 2005-10-26 15:01:09 UTC
many tags are lost again.
Comment 45 Martin Hollmichel 2005-11-13 15:35:49 UTC
*** Issue 57818 has been marked as a duplicate of this issue. ***
Comment 46 Martin Hollmichel 2005-11-13 15:37:27 UTC
*** Issue 57817 has been marked as a duplicate of this issue. ***
Comment 47 Unknown 2006-01-06 02:06:19 UTC
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
Comment 48 jens-heiner.rechtien 2006-01-09 14:16:30 UTC
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
Comment 49 jens-heiner.rechtien 2006-01-09 14:16:48 UTC
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
Comment 50 Unknown 2006-01-24 18:03:09 UTC
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.
Comment 51 Martin Hollmichel 2006-10-09 16:20:32 UTC
close issue.