Re: Sharing code between different projects?

andrea crotti wrote:
> 2012/8/14 Cameron Simpson <cs@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@rev1

B
- common@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