andrea crotti wrote:
2012/8/14 Cameron Simpson <c...@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
--
http://mail.python.org/mailman/listinfo/python-list
