Risks in renaming branches ?

[Marc Girod]

>>>>> "FS" == Frank Schophuizen <fs5628@hotmailnospam.com> writes:

FS> It is not recommended practice.

??? A bit hasty and global, IMHO.

FS> As soon as you rename the branch name, all versions on the branch
FS> will become invisible to users (immediately, if using dynamic
FS> views).

Almost correct (1), so better be prepared. If this is what you want (2),
then OK. It can be a "recommended practice".

FS> You will need to modify all config-specs according to make it
FS> visible again.

Not necessarily. It depends on what you rename it *to*.

1. As a matter of fact, it *won't* affect immediately other dynamic
views in the same site. It will affect them only after they
re-evaluate their config spec, e.g. with "ct setcs -current". One
could even argue that *this* is a drawback of the technique.

2. Renaming branches can be used (and recommended) for publication /
delivery: instead of *merging* to your "integration" branches, you
chtype or (depending on the cases) rename your "development"
branches to them. One *huge* advantage is that doing so, you
*promote* your existing derived objects to a "shareable" status.

--
Marc Girod 313 Fairchild Drive desk: +1 650 864 6501
Nokia NBI CA 94043 Mountain View mobile: +1 817 703 8975
Bld C #314 USA fax: +1 650 691

[Marc Girod]

>>>>> "FS" == Frank Schophuizen <fs5628@hotmailnospam.com> writes:

FS> Are you sure this is correct????

Check it yourself:

$ ct catcs -tag mgirod_tmp
element * CHECKEDOUT
element * .../foo/LATEST
element * /main/LATEST
$ ct mkbranch -nc -nco foo .
Created branch "foo" from "." version "/main/0".
$ ct startview mgirod_tmp
$ ct ls -d /view/mgirod_tmp$(pwd)
/view/mgirod_tmp/vob/tst1/.@@/main/foo/0 Rule: .../foo/LATEST
$ ct rename brtype:foo bar
Renamed branch type from "foo" to "bar".
$ ct ls -d /view/mgirod_tmp$(pwd)
/view/mgirod_tmp/vob/tst1/.@@/main/bar/0 Rule: .../foo/LATEST
$ ct setcs -tag mgirod_tmp -current
$ ct ls -d /view/mgirod_tmp$(pwd)
/view/mgirod_tmp/vob/tst1/.@@/main/0 Rule: /main/LATEST
$

I.e. the .../foo/LATEST rule still applies even after there is no foo
brtype anymore.

FS> IMHO, renaming branches to change the objective (from
FS> "development" to "integration") is bad practice.

It is not the "objective" one changes, it is the state.
Semantics always ultimately require an observer.

FS> "This is not bug, it is a feature"

Its work.

--
Marc Girod 313 Fairchild Drive desk: +1 650 864 6501
Nokia NBI CA 94043 Mountain View mobile: +1 817 703 8975
Bld C #314 USA fax: +1 650 691

[Bob]

Marc Girod <girod@shire.ntc.nokia.com> wrote... $ ct catcs -tag mgirod_tmp element * CHECKEDOUT element * .../foo/LATEST element * /main/LATEST $ ct mkbranch -nc -nco foo . Created branch "foo" from "." version "/main/0". $ ct startview mgirod_tmp $ ct ls -d /view/mgirod_tmp$(pwd) /view/mgirod_tmp/vob/tst1/.@@/main/foo/0 Rule: .../foo/LATEST $ ct rename brtype:foo bar Renamed branch type from "foo" to "bar". $ ct ls -d /view/mgirod_tmp$(pwd) /view/mgirod_tmp/vob/tst1/.@@/main/bar/0 Rule: .../foo/LATEST $ ct setcs -tag mgirod_tmp -current $ ct ls -d /view/mgirod_tmp$(pwd) /view/mgirod_tmp/vob/tst1/.@@/main/0 Rule: /main/LATEST $ I.e. the .../foo/LATEST rule still applies even after there is no foo brtype anymore.

Doesn't reproduce on Solaris with either (patched) v2002 or v2003...
What release are you running?

[Marc Girod]

>>>>> "Bob" == Bob <25inchhatch@my-deja.com> writes:

Bob> Doesn't reproduce on Solaris with either (patched) v2002 or
Bob> v2003...

Very strange indeed. Precisely my transcript, you are sure?
You noted that I am not in the mgirod_tmp view myself? I do the rename
from an other view...

Bob> What release are you running?

Patched v2002 on RedHat 7.3, with vobs on Solaris, but I have had this
same behaviour everywhere since v2 (HP-UX, Windows, Solaris,
Linux...)

--
Marc Girod 313 Fairchild Drive desk: +1 650 864 6501
Nokia NBI CA 94043 Mountain View mobile: +1 817 703 8975
Bld C #314 USA fax: +1 650 691