[p4] perforce "svn:externals" equivalent

Johan Nilsson r.johan.nilsson at gmail.com
Wed Aug 25 06:54:30 PDT 2010

Chuck Karish wrote:
> On Tue, Aug 24, 2010 at 11:31 PM, Johan Nilsson
> <r.johan.nilsson at gmail.com> wrote:
>> Ilya Kazakevich wrote:
>>> Hello,
>>> I have several libraries I want to share between my projects. All
>>> they are in //myDepo/myLibraries/
>>> So, I want to have folder "myLibraries" in my projects. In SVN I
>>> could do so using "svn:external" attribute that makes my folder
>>> content to be fetched from another folder each time I do "update"
>>> ("sync" in perfoce terms).
>>> Is it possible to achieve same functionality in perforce?
>> No, unfortunately. But please tell Perforce Support - they should
>> have an enhancement request logged for this which they can add your
>> name to. The more the better ...
> This restriction has been in the migration FAQ, in response to
> questions like "How do I implement VSS shares?", for more than ten
> years.  Don't hold your breath.

I'd be dead since years if I had ... :)

>>> I was
>>> thinking about workspace mapping:
>>> //myDepo/myProject/... //myWorkSpace/myProject/...
>>> //myDepo/myLibraries/... //myWorkSpace/myProject/libraries/...
>>> But I really do not like this idea because I believe this info
>>> should be part of depo, not workspace.
>> Agreed.
> Write a tool that users and scripts can use to generate correct
> client views.
>>> Additionally I am not sure it will
>>> work fine.
>> It will work.
>>> So, is it possible to solve it on VCS layer?
>> I tend to use branching for this purpose, e.g.:
>> p4 integrate //myDepo/myLibraries/...
>> //myDepo/myProject/myLibraries/...
>> It is a bit heavier than using workspace mapping (can create quite a
>> bit of metadata depending on complexity of "myLibrary") but is
>> easier to maintain, IMHO of course. Single-line workspace/client
>> definitions are a Good Thing(tm).
> This requires recurring work to keep all the instances of the library
> up to date.  If many products use the library other problems of scale
> will arise; this solution uses a lot of server resources.

Normally applications should depend on a specific/released version of a 
library (e.g. under //depot/.../myLib/1.0/...) and not on a branch in flux, 
so that should not be a big problem in terms of "keep all instances ... up 
to date".


More information about the perforce-user mailing list