To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=86975
Issue #|86975
Summary|cwscreate fails to create a CWS which was planned for
|a different master trunk
Component|tools
Version|OOo 2.3
Platform|All
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P3
Subcomponent|solenv
Assigned to|hr
Reported by|fs
------- Additional comments from [EMAIL PROTECTED] Wed Mar 12 20:46:23 +0000
2008 -------
There is a CWS odbmacros3, which was planned at a time where SRC680 was our main
development trunk. Now, it came to actually creating the CWS, using cwscreate,
which is expected to create a physical copy of the CWS, and promote it from
status "planned" to "new" in EIS.
Since DEV300 is our current development trunk, I did
setsolar -dev300 -ver m2 -pro -jdk14 unxlngi6
cwscreate -p unxlngi6,wntmsci11,unxlngi6.pro DEV300 m2 odbmacros3
This miserably failed, with an error message saying that the name odbmacros3 is
already in use. Well, yes, that's true - I just asked to promote it, didn't I?
Peeking into cwscreate.pl revealed the root cause: An instance of "Cws" is
created, and this is initialized with the major/minor combination which was
specified at the command line - DEV300:m2, in this case. Then, this CWS is asked
for its EIS ID, which is 0. Actually, there exists a CWS with name odbmacros3,
but its major is SRC680, not DEV300, so DEV300/odbmacros3 is not found.
Thus, cwscreate.pl assumes it needs to create the CWS from scratch, and does a
last check "$cws->is_cws_name_available()", which returns 0, which causes
cwscreate to fail.
Conclusions:
1. cwscreate needs to be more intelligent in finding the existing CWS in EIS,
either automatically, or with a new command line switch allowing to specify the
master of the planned CWS.
2. Our current mechanism to use a master and the mere name ("SRC680/odbmacros3")
to uniquely identify a CWS is bogus: cwscreate itself refuses to continue if the
mere name is already used, no matter for which master.
Corollary: When reworking our CWS handling to adjust it to SVN, we should throw
away the "master in CWS name" feature, since it has several other disadvantages,
and does not work at all, as we've seen here.
(side note: there's no easy workaround for the problem: "setsolar -src680 ..."
does not work, since then cwscreate complains that it needs an environment which
equals the env of the to-be-created CWS. Creating the CWS for SRC680, and then
resyncing it, is not really a good option.
I finally hacked the cwscreate.pl script. It's currently running, let's see
whether the hack was successful :)
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
