Topic
  • 6 replies
  • Latest Post - ‏2013-02-08T11:28:12Z by SystemAdmin
SystemAdmin
SystemAdmin
47293 Posts

Pinned topic Working on same branch in different replicas

‏2013-02-05T15:52:35Z |
In a simplified description we have two sites (siteA and siteB), where siteA has the responsibility of productA and site B has the responsibility of productB in the same vob (cool_products). The folder structure in the vob is:

/vobs/cool_products/productA
/vobs/cool_products/productB

Lets say siteA has the mastership of the main branch type.

Is it possible to let siteB have the mastership of the main branch in productB and all files and folders beneath productB?

We have tested with multitool chmaster on productB and everything beneath it. And it works fine until someone at siteB wants to create a new file (or folder). Then we get the error message that siteB is not master of main and therefore only newfile.txt@@/main/0 is created (not newfile.txt@@/main/1). It looks like all new files must be created at siteA and then the mastership has to be transferred to siteB after creation. Is there a way to simplify this?

/Atle
  • SystemAdmin
    SystemAdmin
    47293 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-05T16:17:29Z  
    aer999 wrote:
    > Is there a way to simplify this?

    Yes, the
    -master
    
    option...
    But don't do that...
    You'll just make your own life difficult, full of surprises etc.
    The simple way is to avoid giving a meaning in advance to branches: create them as you need them, and use labels instead.
    There is a simple rationale for that: labels can be aliased (same version, different labels).
    Branches cannot.
    Marc
  • brcowan
    brcowan
    763 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-05T16:47:46Z  
    mkelem -master will do exactly what you're looking for (and it has a equivalent checkbox in the GUI, FYI). However, I would ask a slightly different question: Why not give the ProductB team its own VOB for code unique to that product? That avoids mastership issues entirely, and will reduce the "why can't I" calls and emails when mastership issues get in the way.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
  • SystemAdmin
    SystemAdmin
    47293 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-05T17:31:19Z  
    Thanks for your answers. The -master switch does exactly what I asked for. However it seems that both of you recommends to separate out productB in it's own VOB instead of using the -master switch. We will probably split the VOB and follow your recommendation.

    /Atle
  • SystemAdmin
    SystemAdmin
    47293 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-06T21:01:45Z  
    Thanks for your answers. The -master switch does exactly what I asked for. However it seems that both of you recommends to separate out productB in it's own VOB instead of using the -master switch. We will probably split the VOB and follow your recommendation.

    /Atle
    aer999 wrote:
    > However it seems that both of you recommends to separate out productB in it's own VOB
    While I reckon that spitting vobs will avoid the problem, this is not what I recommended.
    I recommended to change the process, and to use branches differently.
    In other words, to use a process not depending on mastership.
    All mastership issues are self-inflicted wounds.
    The chmaster command is necessary: it is used after creating a new replica, to make it self-mastered, and while removing a replica and thus a local vob copy). It is never needed otherwise.
    Marc
  • SystemAdmin
    SystemAdmin
    47293 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-07T07:50:04Z  
    aer999 wrote:
    > However it seems that both of you recommends to separate out productB in it's own VOB
    While I reckon that spitting vobs will avoid the problem, this is not what I recommended.
    I recommended to change the process, and to use branches differently.
    In other words, to use a process not depending on mastership.
    All mastership issues are self-inflicted wounds.
    The chmaster command is necessary: it is used after creating a new replica, to make it self-mastered, and while removing a replica and thus a local vob copy). It is never needed otherwise.
    Marc
    > In other words, to use a process not depending on mastership.

    To be a bit more specific, during development we usually work on different branches on siteA and siteB. But before we make a release we merge everything back to main and label the release on the main branch. We could change the process to merge back to a delivery branch instead. But to avoid mastership issues we need more then one delivery branch. We could choose to have one delivery branch for each product or site.

    Marc: Is this closer to your recommendation?
    However I'm not sure what you mean by: "The simple way is to avoid giving a meaning in advance to branches: create them as you need them, and use labels instead." In other words you allow releases to be labelled on whichever branch the developers happen to use?

    /Atle
  • SystemAdmin
    SystemAdmin
    47293 Posts

    Re: Working on same branch in different replicas

    ‏2013-02-08T11:28:12Z  
    > In other words, to use a process not depending on mastership.

    To be a bit more specific, during development we usually work on different branches on siteA and siteB. But before we make a release we merge everything back to main and label the release on the main branch. We could change the process to merge back to a delivery branch instead. But to avoid mastership issues we need more then one delivery branch. We could choose to have one delivery branch for each product or site.

    Marc: Is this closer to your recommendation?
    However I'm not sure what you mean by: "The simple way is to avoid giving a meaning in advance to branches: create them as you need them, and use labels instead." In other words you allow releases to be labelled on whichever branch the developers happen to use?

    /Atle
    aer999 wrote:
    > Marc: Is this closer to your recommendation?
    No. My recommendation is not to have integration branches (of a pre-defined type) at all!
    To have only integration labels.

    Marc