Hi Martina,
If I get you right you want to give the mastership of the main branch to
replica B in one directory and keep it in replica A in another. This won't
work, because CC/MS can handle masterships only for the entire branch, no
matter in which directory it is used (as long as you are in one VOB). So, if
there are changes to be made in replica B, they have to use their own branch
type.
Why are your people so scared about merging? Automatic merging works fine at
our site (except for some files of course where an automatic merge is not
possible).
Maybe the merge manager in 3.2.1 isn't what it should be - we use the
merging as it was in CC 3.2. I just replaced the file
"file_pulldown_B_versions.grp" in /usr/atria/config/ui/grp/ with the same
file from the 3.2-Release.
Transfering the mastership of a branch to site B needs a syncreplica of
course. But you won't have to wait for it - just issue the syncreplica
command manually any time you want (multitool syncreplica -export -fship ...
).
Hope this helps
Bernd
> ----------
> Von: Riedel, Martina[SMTP:Martina.Riedel@icn.siemens.com
> Gesendet: Donnerstag, 20. Januar 2000 19:45
> An: 'cciug@Rational.Com'
> Cc: Payne, Charlotte; Birkl Thomas ICN WN ES D 423
> Betreff: [cciug] multisite question
>
>
> Hi all,
> We want to transfer the master ship of some files to avoid branching in a
> multisite env. So far I haven't been successful at selling a merge
> concept.
> Nobody wants to do the (hopefully trivial) merges.
> As there is also a maintenance branch involved, I think there is a snag in
> the whole concept though.
> I'd appreciate comments.
>
> Site A owns /main of directory D1 and all files in it.
> Site B owns /main of Directory D2 and all files in it (the mastership is
> planned to be transferred from Site A)
> Branch type 'newrel' has been created and is owned by site A.
>
> Developers at both sides develop the new release and update their files.
> If they need to make a change to a file that is incompatible with the old
> release, they need to make these changes on newrel branch, i.e. do a
> mkbranch. (there are more releases and branches existing, so yes, the new
> work needs to be on the branch)
>
> For D1 and Site A there is no problem.
>
> For D2 I don't know. As the mastership isn't transferred yet and I have no
> test VOB available I can't try.
> I'm thinking that instances of newrel can only be created at Site A, and
> then the mastership could be transferred.
> We do want to avoid just making the branches now, as also bugfixing is
> ongoing and it is not known right now which files will have compatible and
> which will have incompatible changes.
> Doing it on an as need base will be a support nightmare and we'd have to
> wait for the replication to happen.
>
> Any great ideas anybody?
> Martina
> Don't Postpone Joy - Have Fun
> Martina Riedel Siemens Information and Communication
> Networks
> phone: 561-997-3774 Martina.Riedel@ICN.Siemens.com
> <mailto:Martina.Riedel@ICN.Siemens.com>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:22:33 EDT