This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 56192 - update CVS tag database (checkout from branch impossible)
Summary: update CVS tag database (checkout from branch impossible)
Status: RESOLVED INVALID
Alias: None
Product: obsolete
Classification: Unclassified
Component: collabnet (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: support
URL:
Keywords:
Depends on:
Blocks: 50893
  Show dependency tree
 
Reported: 2005-03-10 17:39 UTC by rbalada
Modified: 2009-11-08 02:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
test case for checkout branches (6.50 KB, text/plain)
2005-03-11 09:10 UTC, rbalada
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rbalada 2005-03-10 17:39:26 UTC
After upgrade it is impossible to checkout sources from branches. Each and every
branch does not work. It is possible to make the respective branch checkout work
by checkout of trunk and then update to respective branch. As we have a plenty
of branches this approach is not viable. I ask yout to update the CVS tag
database directly on server side.

There is a workaround:
If I checkout trunk, I can then update to branch. After such an update checkout
from the respective branch appears to work.

Please do not lower priority, this defect affects many teams and release cycles.

My configuration:
$ cvs -d :pserver:rbalada@cvs.netbeans.org:/cvs version
Client: Concurrent Versions System (CVS) 1.11 (client/server)
Server: Concurrent Versions System (scast-vc-1.5.2) (CVS) 1.11.1p1 (client/server)
$ 

$ cvs -d :pserver:rbalada@cvs.netbeans.org:/cvs co -rbowfixes nbbuild
lock.c:222: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'
cvs [server aborted]: received abort signal
lock.c:222: failed assertion `strncmp (repository,
current_parsed_root->directory, strlen (current_parsed_root->directory)) == 0'
cvs [server aborted]: received abort signal
$
Comment 1 Unknown 2005-03-10 20:00:18 UTC
I verified that checking out branches works fine.
Here are the details:

My configuration:
cvs -d :pserver:asarkar@cvs.netbeans.org:/cvs version
Client: Concurrent Versions System (CVS) 1.11.2 (client/server)
Server: Concurrent Versions System (scast-vc-1.5.2) (CVS) 1.11.1p1 
(client/server)

Verfied:
cvs -d :pserver:asarkar@cvs.netbeans.org:/cvs co -rbowfixes nbbuild
cvs server: Updating nbbuild
cvs server: Updating nbbuild/antsrc
.....
.....
cvs server: Updating nbbuild/www/proposals/scrambler

$cd nbbuild
$cvs -d :pserver:asarkar@cvs.netbeans.org:/cvs status

===================================================================
File: .cvsignore        Status: Up-to-date

   Working revision:    1.15
   Repository revision: 1.15    /cvs/nbbuild/.cvsignore,v
   Sticky Tag:          bowfixes (branch: 1.15.20)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
File: build.properties  Status: Up-to-date

   Working revision:    1.129.6.1
   Repository revision: 1.129.6.1       /cvs/nbbuild/build.properties,v
   Sticky Tag:          bowfixes (branch: 1.129.6.1.6)
   Sticky Date:         (none)
   Sticky Options:      (none)

===================================================================
....
------------------------

I am marking this issue as resolved. If you still have issues, please re-open.

Comment 2 rbalada 2005-03-11 09:10:15 UTC
Created attachment 20768 [details]
test case for checkout branches
Comment 3 rbalada 2005-03-11 09:16:02 UTC
Please use the attached shell script as a test case. The issue is still there
for other tags/branches. Fix it globally for each and every cvs tag in
repository. This test case is just ~120 branches, but there are hundreds of cvs
tags which must also get into the tag database.

Unfortunatelly there is workaround how to update the tag database for single tag
and I tested the workaround for the bowfixes branch what caused the original
test of this issue stopped showing error.

This is still P1
Comment 4 jcatchpoole 2005-03-15 17:19:13 UTC
Collab, can you pls respond ?  This is another upgrade related problem; we need
to get all these closed and done ASAP so we can get back to work.  Until then
we're in a state of limbo and can't consider the upgrade complete.  

If you need more info/details from Rudo pls ask.  Thanks.
Comment 5 Unknown 2005-03-16 15:16:15 UTC
I am able to reproduce the error , have requested the operations to run a script
which would fix this particular issue , the internal issue reference no is
35550, will be updating with the status of the issue when the script has been
runned .

Jobin.
Comment 6 Unknown 2005-03-16 15:28:00 UTC
Bringing down the priority ,since running the script is excepted to fix this issue 

Jobin.
Comment 7 Unknown 2005-03-16 15:43:29 UTC
This issue is given the highest priority in the internal issue and the
operations will be working on this issue first thing in the morning .
Comment 8 rbalada 2005-03-16 16:35:57 UTC
jobin,

running the script multiple times should not fix the issue.

The workaround is 

1. *checkout* from trunk
2. *update* to branchX
3. *update* to branchY
4. *update* to tagXYZ
....


this procedure fixes the tag database for branches "branchX" and "branchY" and
for tag "tagXYZ". The attached script does just *checkout* for ~120 branches.
Multiple executions should not fix the tag database as there is missing the very
initial checkout from trunk and then serie of *updates*.

Compared to issue 56348, this issue it not that hot.
Comment 9 jcatchpoole 2005-03-16 16:41:42 UTC
Rudo, I don't think Jobin is talking about your script.  He mentions "a" script
which will fix the issue, but that does not (necessarily) mean your attached script.
Comment 10 Unknown 2005-03-16 20:04:41 UTC
Jack is right.  We have a script which goes out and collects tags from the 
entire site and repopulates val-tags and it has been run.  Please confirm is 
this problem still exists.
Comment 11 rbalada 2005-03-16 20:19:24 UTC
I cannot reproduce the problem anymore.
Comment 12 Unknown 2005-03-16 21:30:40 UTC
closing.
Comment 13 Unknown 2006-09-11 07:40:14 UTC
I have verified  the issue,  I was not able to reproduce the issue.

Regards,
Ramya
Support Operations
Comment 14 Marian Mirilovic 2009-11-08 02:34:22 UTC
We recently moved out from Collabnet's infrastructure