[p4] Strategy for tracking 3rd-party packages

[Mats Nilsson]

Hi list!

(This is a resend due to me using the wrong account for posting - sorry
if you receive duplicates)

In evaluation of Perforce for our organization, I'm wondering about a
good strategy for how to lay out the repository to be able to track the
evolution of third party libraries, along with local modifications.

I've followed discussions on the subversion
(http://subversion.tigris.org) mailing lists regarding this, and the
common advice for subversion repositories is to make sure that files of
subsequent releases are first introduced on a single codeline, and then
tagged (by making a copy). This way proper ancestry is maintained for
all files. Since p4 and subversion repositories are similar in the sense
that codelines and filenames share a common namespace, I thought that
the same strategy would make sense for Perforce as well.

So I tried the following layout and integration scheme, tracking
releases of a ficticious third party package "pkga".

   //depot/pkg/pkga/import -+-------+-->
                             \       \
   //depot/pkg/pkga/v1        v-+-->  \
                                 \     \
   //depot/pkg/pkga/v2            \     v-+-->
                                   \       \[*]
   //depot/pkg/pkga/local           v-+-----v---+-->
                                       \         \
   //depot/pkg/pkga/v1-local            v-->      \
                                                   \
   //depot/pkg/pkga/v2-local                        v-->


All files are first introduced in the "import" directory, and are
branched off to corresponding version directories "v1", "v2".

Local changes have a codeline of its own, receiving patches from
successive version directories.

Stable checkpoints of the local codeline are branched off to "v1-local"
etc.


I run into a problem with this:

At the point [*], when integrating (using a filespec) the "v2" branch
into the "local" branch, p4win wont perform the integration unless I
enable baseless merges. After all the work I've done, it seems perforce
doesn't recognize that there exists a proper common base.

Why is this? Would this be a problem in this context? Can this be
circumvented in any way by structuring this differently? 

I'm using branches instead of labels, simply because the former is a
versioned resource, and the latter is not. It seems safer. And it seems
easier to refer to a branch instead a branch#label when setting up
client mappings.

Grateful for any comments on this.

Thanks

Mats Nilsson