Issue 105135 - Creating a HG-based CWS via command spits error
Summary: Creating a HG-based CWS via command spits error
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: DEV300m59
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-09-17 01:57 UTC by kyoshida
Modified: 2013-01-29 21:45 UTC (History)
3 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description kyoshida 2009-09-17 01:57:25 UTC
When I just tried to create a new mercurial based cws via the cws command, it
spits out an error message, but somehow succeeds in creating a new cws.

Here is the command run and its output:
$ cws create --hg -m m59 DEV300 calcphonetic
Warning: web service unavailable. Trying backup server.
ERROR: Connection to EIS database failed.
 at /media/disk/ooo/hg-pilot/koheirowlimitperf/solenv/bin/modules/ line 1839

***** Successfully ***** registered child workspace 'calcphonetic'
for master workspace 'DEV300' (milestone 'm59').
Child workspace Id: 8705.
It creates a new entry in the EIS, but the SCM type is set to CVS, not HG as I
Comment 1 kyoshida 2009-09-17 01:58:52 UTC
Btw, when I omit the milestone, it doesn't even create an entry in the EIS. 
According to the help output of the cws command, you are supposed to get the
latest published milestone if you don't specify the milestone.
Comment 2 kyoshida 2009-09-17 02:06:27 UTC
I forgot to mention that, I have used the cws tool that comes with m59.
Comment 3 jens-heiner.rechtien 2009-09-17 11:45:02 UTC
@kohei: did you update solenv/bin/ also to m59 level? I made a few
API changes there and the problem with the milestone and the left out setting of
the HG flag could be caused by a mismatch.
Comment 4 kyoshida 2009-09-17 16:03:01 UTC
@hr: I assume so, since I rebased the entire cws to m59.

Here is my hg log output on solenv/bin/modules/

$ hg log solenv/bin/modules/ 
changeset:   262998:fdf76db01ccd
user:        releng
date:        Thu Aug 27 15:47:51 2009 +0000
summary:     CWS-TOOLING: integrate CWS hr65

changeset:   262531:d853316ba75f
user:        vg
date:        Tue Mar 17 00:00:46 2009 +0000
summary:     CWS-TOOLING: integrate CWS hr60_DEV300

changeset:   262026:6e75d9dd4600
user:        kz
date:        Thu Nov 06 16:01:03 2008 +0000
summary:     CWS-TOOLING: integrate CWS rt34

Comment 5 jens-heiner.rechtien 2009-09-17 16:25:05 UTC
@kohei: Having everything on hr65 level rules out an incompatibility between and Looks like you were victim of yet another temporary
webservice outtage. I've have to look why the script didn't completely bail out
after the first difficulty. This fallback thing needs to be removed as well,
it's no longer really applicable. I would assume that if you create another CWS
everything would be fine. Which URL do you use in your $HOME/.cwsrc?

'cc Bernd.
Comment 6 kyoshida 2009-09-17 16:33:20 UTC
Here is the server line in my .cwsrc:


But the command *did* create a new entry in the EIS database.  So, I'm a bit
skeptical it was the server...
Comment 7 jens-heiner.rechtien 2009-09-17 16:41:28 UTC
All the  SOAP requests are independent. It might very well be that the query for
the latest milestones fails, the next query (for example the registration)
works. The script should bail out if one request fails, but if it does after
registration but before marking the CWS as HG based it would leave an
incompletely initialized CWS. I would like some rollback possibility here :-) Or
one API call to do all the writing requests in one go.
Comment 8 kyoshida 2009-09-17 17:42:23 UTC
BTW cws creation still fails even right now.

$ cws create --hg -m m59 DEV300 calctabcolor
Warning: web service unavailable. Trying backup server.
ERROR: Connection to EIS database failed.
 at /media/disk/ooo/calcphonetic/solenv/bin/modules/ line 1839

***** Successfully ***** registered child workspace 'calctabcolor'
for master workspace 'DEV300' (milestone 'm59').
Child workspace Id: 8706.
Comment 9 jens-heiner.rechtien 2009-09-17 18:36:33 UTC
Some of the EIS servers were down, broken UPS. I'll have a look at it tomorrow
when the situation settles.
Comment 10 jens-heiner.rechtien 2009-09-18 14:28:56 UTC
@kohei: I was able to reproduce it now. It's probable the EIS service. I'll
contact Bernd.
Comment 11 kyoshida 2009-09-18 15:22:26 UTC
@hr: thank you, and I'm glad to see you have been able to reproduce this.
Comment 12 bernd.eilers 2009-09-18 16:33:49 UTC
bei->kohei: I have made a fix in EIS in the cws create method but I am not sure
if that was the one needed in your case . Can you please try again to create a
Comment 13 kyoshida 2009-09-18 17:08:01 UTC
@bei: yup, it worked.  I just created (and deleted) koheitestcws01.  It was
correctly registered as an HG-based CWS.
Comment 14 kyoshida 2009-10-02 16:41:34 UTC
Re-opening.  I just had the same problem again just now, with the creation of
koheicopyborder cws.
Comment 15 jens-heiner.rechtien 2009-10-02 18:59:57 UTC
@bei: reassign
Comment 16 bernd.eilers 2009-10-05 13:30:10 UTC
bei->kohei: can not reproduce an error. If it was excatly the same error as
described at first occurance than I would suppose it was just a temporary outage
of the eis service. If you got another error message for the last occurrence
than "web service unavailable" please describe the error message. Errors like
the SOAP method is throwning an exception because for example an argument is not
being accepted or if there is a null pointer access or if the SOAP service is
not correctly deployed should result in a different error message than "web
service unavailable."
Comment 17 kyoshida 2009-10-05 13:43:45 UTC
@bei: The error output was exactly the same (except for the cws name) as in desc1.
Comment 18 bernd.eilers 2009-10-12 16:29:33 UTC
occured for annother user to reopening
Comment 19 thb 2009-10-12 16:48:09 UTC
Which was me. Cc-ing myself.
Comment 20 thb 2009-10-14 11:57:13 UTC
Played a bit with it. First suspected a 64bit problem, but then tried it on a
x86_64 fc11 install, and it works there.

Current theory: specific version of client libs don't play nice with server (we
might need to compare things on packet level for further info). These are the
versions of the relevant libs:


opensuse 11.0

(fc11: works. opensuse 11.0: doesn't work)