Reuse of branchs useful?

[DavidJeskejeske at home.chat.net]

On Wed, Jun 03, 1998 at 08:41:43AM +0200, Robert M. M=FCnch wrote:
> Now the question is after they have done the branch, and after there is
> a new version ready to be branched again, does it make sense to edit th=
e
> branch specifiction of the branch 'internal-release' to something like
> this:
>=20
> \\depot\main\proj1\... \\depot\internal-release\proj1\19-June-98\...
>=20
> Or would it be better to create a new branch? I'm not sure if I re-use =
a
> branch specifiction that Perforce is still able to keep track of all th=
e
> branches.

The branch specification just creates a "shortcut" for describing the
integrate relationships for a set of files. For example, if you want to p=
ush
a change from one place to another, you can either specify BOTH files via
the integrate command, OR you can specify one of the files and name the
branch it's a part of. It then takes that one file, looks it up in the
branch specification, and maps it to it's destination according to that
branch.

So, you do lose information and functionality when you delete a branch
specification. It would be better to name your branches appropriately.
=20
> 2.
> Is there a fast and easy way to find out from which other code-line the
> branched-version was created from? I have seen that it's possible to us=
e
> the 'properties' menu in the GUI and find out the changelist-number,
> than I have to get the change-list description... not very comfortable.

If you look at the first changenumber for a file it will specify the
changelist which the branch was performed in (if it was a branch) and fro=
m
that you can find the source file.=20

However, I agree that this isn't what you want. You really want the branc=
h
specification name which was performed. I think the only way to get this
would be to look through all the branch specifications and find a match f=
or
'both' files you just found above.=20

> It would even be a very cool feature to see a graph, how each depot
> branch relates to others.

You can do this if you keep around all the branch specifications, just op=
en
them all up and look at them.=20

- ----

I agree that this stuff isn't the cleanest part about Perforce. IFB is co=
ol,
but it also clouds the distinction between a project and a directory with=
in
the project (i.e. there is no difference) and there is also no distinctio=
n
between a branch and a directory, so it's a little weird to access some o=
f
the data.

- --=20
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske at chat.net