[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".

Regards,
Johan





More information about the perforce-user mailing list