Sharing code between different projects?

[Jean-Michel Pichavant]

andrea crotti wrote:
> 2012/8/14 Cameron Simpson <cs at zip.com.au>:
>   
>> Having just skimmed this thread, one thing I haven't quite seen suggested is
>> this:
>>
>> Really do make a third "utilities" project, and treat "the project" and
>> "deploy" as separate notions. So to actually run/deploy project A's code
>> you'd have a short script that copied project A and the utilities project
>> code into a tree and ran off that. Or even a simple process/script to
>> update the copy of "utilities" in "project A"'s area.
>>
>> So you don't "share" code on an even handed basis but import the
>> "utilities" library into each project as needed.
>>
>> I do this (one my own very small scale) in one of two ways:
>>
>>   - as needed, copy the desired revision of utilities into the project's
>>     library space and do perforce's equivalent of Mercurial's addremove
>>     on that library tree (comment "update utilities to revision X").
>>
>>   - keep a perforce work area for the utilities in your project A area,
>>     where your working project A can hook into it with a symlink or some
>>     deploy/copy procedure as suggested above.
>>     With this latter one you can push back into the utilities library
>>     from your "live" project, because you have a real checkout. So:
>>
>>       projectAdir
>>         projectA-perforce-checkout
>>         utilities-perforce-checkout
>>       projectBdir
>>         projectB-perforce-checkout
>>         utilities-perforce-checkout
>>
>>     
>
> Thanks, is more or less what I was going to do..  But I would not use
> symlinks and similar things, because then every user should set it up
> accordingly.
>
> Potentially we could instead use the perforce API to change the
> workspace mappings at run-time, and thus "force" perforce to checkout
> the files in the right place..
>
> There is still the problem that people should checkout things from two
> places all the time instead of one..
>
>   
SVN allows to define external dependencies, where one repository will 
actually checkout another one at a specific version. If SVN does it, I 
guess any decent SCM also provide such feature.

Assuming our project is named 'common', and you have 2 projects A and B :

A
    - common at rev1

B
    - common at rev2

Project A references the lib as "A.common", B as "B.common". You need to 
be extra carefull to never reference common as 'common' in any place.

JM