Topic
3 replies Latest Post - ‏2013-08-26T22:49:30Z by Dave-Robinson
JirongHu
JirongHu
680 Posts
ACCEPTED ANSWER

Pinned topic Resolve evil-twin

‏2013-08-21T21:29:04Z |

M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WC\xml\configwc-server.targetable.hbcdact2.xml has (2) evil twins at:

       {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WC\xml\config@@\main\JAWC_Main\C997388_JAWC_R3\1\wc-server.targetable.hbcdact2.xml

        {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WC\xml\config@@\main\JAWC_Main\C997403_JAWC_R3\1\wc-server.targetable.hbcdact2.xml

 

Solution 1:

To resolve the above evin-twin, I "rmelem" the file from one of the stream, then I can't see it from the other stream as well. Now when developer wants to add back the file, they got this error. The message is from my "evil-twin" trigger. How to fix this?

CRVAP0087E CCRC command 'Mkelem' failed: Unable to create new element for "D:\CCWEB\C997408\C997408_JAWC_R3\Java_AVOB\JAWC_wkspc\WC\xml\config\wc-server.targetable.hbcdact2.xml"

Error: duplicate name 'wc-server.targetable.hbcdact2.xml' found in directory version config@@/main/JAWC_Main/C997403_JAWC_R3/3

 

Solution 2:

My problem is the same file was added many times to different private streams by different users. Can do the following to clean up:

1. rmelem all instances.

2. delete the parent directory version which added that file.

This makes like this file was never exist. Then we will add it again.

 

Solution 3:

Today somebody gives a creative thinking. Lock/obselete all private branches created the evil-twin and re-create them from the parent. So from this point, only the version on the parent will be used. Will this work?

 

Please comment, thanks

Jirong

 

Updated on 2013-08-22T17:30:19Z at 2013-08-22T17:30:19Z by JirongHu
  • Dave-Robinson
    Dave-Robinson
    116 Posts
    ACCEPTED ANSWER

    Re: Resolve evil-twin

    ‏2013-08-26T02:06:43Z  in response to JirongHu

    Re: Solution 1

    The issue is that JUST doing the rmelem has not RESOLVED the evil-twin, since the developer cannot see any version of what you consider the TRUE file - hence the developer tries what he/she THINKS he/she needs, and tries to create the file, but is just creating another evil twin.

    Re: Solution 2

    Just deleting directory versions which added the file does NOT get all developer views to look at the main / integration branch of the parent directory. Again the developers shall try creating the file.

    Re: Solution 3

    This thinking is starting to go in the right direction, but lock / obsolete of private branches does not stop the developers view from using those branches - in fact you cannot lock a branch (of a specific element - you can lock a brtype)

     

    You DO need to "re-create them from the parent".

    What this actually means is:

    1. rmelem the evil-twin  (save copy if you want to merge the content)

    2. merge the parent directory from the integration branch with the "true" file TO the developer's branch of the parent directory

    After the directory merge, the developer view sees the correct file element. Then the developer can checkout (branch) that element and checkin any different content they need to their private branch of the file element.

    • JirongHu
      JirongHu
      680 Posts
      ACCEPTED ANSWER

      Re: Resolve evil-twin

      ‏2013-08-26T18:39:04Z  in response to Dave-Robinson

      Hi Dave

      Thank you very much for your time, it's much clear to me now. However I still have a bit issue here.

      This is before fix: it says found twins among all these private streams. e.g. c997399_JAWC_R3.1 is the developer c997399's private stream to the release 3.1 integration stream JAWC_R3.1

      M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commandsHBCExtendOrderItemProcessCmdImpl.java has (4) evil twins at:
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\c997399_JAWC_R3.1\1\HBCExtendOrderItemProcessCmdImpl.java
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\C997121_JAWC_R2.1_Dev\1\HBCExtendOrderItemProcessCmdImpl.java
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\c996972_JAWC_R2.1\1\HBCExtendOrderItemProcessCmdImpl.java
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\Q179817_JAWC_R2.1_dev\1\HBCExtendOrderItemProcessCmdImpl.java
       

      So I went into every private stream and did a "rmname" of that file, and then merge from the R3 integration stream to all of them. After that, when I compare the file, it says identical. here "identical" means the same file or same content?

      After the fix, it still lists the following as evil-twins:

      M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commandsHBCExtendOrderItemPrcessCmdImpl.java has (3) evil twins at:
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\JAWC_R3.1\1\HBCExtendOrderItemProcessCmdImpl.java
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\c996972_JAWC_R2.1\2\HBCExtendOrderItemProcessCmdImpl.java
      {one "hidden" from view at} M:\ccadm01_JAWC_R3\Java_AVOB\JAWC_wkspc\WebSphereCommerceServerExtensionsLogic\src\com\hbc\commerce\order\commands@@\main\JAWC_Main\JAWC_R2.1\1\HBCExtendOrderItemProcessCmdImpl.java
       

      These highlighted two versions on the integration stream R3.1 and R3 was delivered by previous private streams created the evil-twins. I can't delete them because there is a deliver/rebase baseline on it. Although I think at this moment, the latest version of each branch is having the same version, what shall I do with this?

      Thanks again

      Jirong

      • Dave-Robinson
        Dave-Robinson
        116 Posts
        ACCEPTED ANSWER

        Re: Resolve evil-twin

        ‏2013-08-26T22:49:30Z  in response to JirongHu

        >>> here "identical" means the same file or same content?

        I am not sure what compare command / operation you did. I expect that it means the file content is identical.

           Note that it is likely that both streams are seeing the same version of the file.

         

        >>> two versions on the integration stream R3.1 and R3 was delivered by previous private streams created the evil-twins. I can't delete them because there is a deliver/rebase baseline on it.

        There is no one right answer about what should be done about this. You are right to be cautious when the evil-twins have become entrenched by being merged.

        Ultimately you have to decide what is the best thing to do in the context of each stream. That shall depend on the state of the project. It the case of complete projects, it is probably best not to remove the data.

        One thing that can be done is to lock the elements you don't want developed further, with lock text telling eny developer who tries that they should contact you of take some specific action.

        You also could use hyperlinks to further document the issue.

        The bottom line is "How does your business need this to be resolved?" I cannot answer that one.

        One thing you may need to do is merge content from one evil-twin into the "blessed" element. There is no "tool" to do this. You just have to checkout the good element on the branch you need it to have, and copy over the checkout from the evil twin.

        The good element cannot get the history of the evil-twin, but by keeping the twin in the VOB and hyperlinking the two together, you can build a composite history if needed.

        Hope that all makes sense!