Menu
▾
▴
[eclipse-ccase-develop] [ eclipse-ccase-Feature Requests-3096488 ] do not use -master for mkelem
|
From: SourceForge.net <no...@so...> - 2010-10-27 15:18:25
|
Feature Requests item #3096488, was opened at 2010-10-27 16:18 Message generated for change (Comment added) made by dmaizer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460300&aid=3096488&group_id=50595 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clearcase Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Reuben Sivan (rsivan) Assigned to: Nobody/Anonymous (nobody) Summary: do not use -master for mkelem Initial Comment: The mkelem command as presently implemented prevents my company users from adding new cc elements from inside eclipse due to a change in mastership for the new file elements. This is likely to happen in all environments on which there are remote master locations. The command we'd like to use is something like: cleartool mkelem –c “some comment” <element name> (without the -master option) Thanks ---------------------------------------------------------------------- Comment By: Danny Aizer (dmaizer) Date: 2010-10-27 17:18 Message: In our case the brtype is also mastered in Location1 as we use pre-defined branch types. So check-out (mastered, reserved) on such a branch when creating an element in Location2 will fail if -master was not specified. This is also certainly ClearCase default behaviour. The case you bring, Reuben, will only result in wrong mastership. The case I bring will result in failure to check-out (/main/other-branch/0, then /main/other-branch/another-branch/0, etc.) and therefore only /main/0 will be created. That's why I think -master should be on by default - mastership of single branch instances can be easily transfered. If an element creation sequence fails - then mastership of a branch type needs to be changed - and this has site-wide implications during the period the branch type is not mastered in the correct replica... Thanks, /Danny ---------------------------------------------------------------------- Comment By: Reuben Sivan (rsivan) Date: 2010-10-27 17:10 Message: I agree this should be configurable, however I disagree on what the default should be; note our case: /main is mastered in Location1 (it has to be in order for them to do merges to it. ) , and we create sub-branches off /main. Normally creating a new element creates /main/0 which is mastered in Location1 and then it branches to <yourname>/0 which is mastered in Location2. This is clearcase default behavior which is correct in our case and then allows Location1 to merge our branched version to /main. I would think the default behavior would be the norm and then have it configurable to –master . Thanks --Reuben ---------------------------------------------------------------------- Comment By: Danny Aizer (dmaizer) Date: 2010-10-27 16:32 Message: While I agree that having -master for cases/configurations is not right, the behaviour I would expect is to have -master included by default. This would mean that branches created due to config_spec rules when creating the element will get the same mastership as the element. Otherwise, if your config_spec has a multi-level branching scheme set-up, and those branch types are mastered in a remote replica of the VOB (or AdminVOB) the creation of sub-branches during element creation will fail with errors. However, I do think that having -master included in mkelem or not should be a configurable option for the plug-in (on by default). This will allow configuration to exclude this option in cases like the one Reuben is describing. Thanks, /Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460300&aid=3096488&group_id=50595 |