[DUG] Source Control - Sharing files between projects

[Paul Heinz]

Berend wrote: 

> Exactly, you branch the /Reference/Core1 to /Project1/Core1
> 
>     David> But my interpretation of your model is that you are relying
>     David> on editing each of the core files within the Reference
>     David> branches and then merging through to the Project
>     David> branches.
> 
> No, the reverse. You edit /Project1/Core1 and merge the 
> changes back to /Reference/Core1 when stable/convenient.
> 
> Perforce handles such merge back really well, unlike more 
> primitive tools.
> 
>     David> Furthermore it is while editing one of the projects that
>     David> you would want to change one of the core files. 
> 
> And you do it exactly there.
> 
>     David> And if developers are editing the core files a various
>     David> project branches then how do you get each of these changes
>     David> reliably merged into the other 7 projects?
> 
> You merge the /Project1/Core1 into /Reference/Core1. Project2 
> developers can merge newer versions of /Reference/Core1 into
> /Project2/Core1 when convenient.
> 
> 
>     David> Unless there is some easy way of automating or at least
>     David> semi-automating this in Perforce?
> 
> Perforce won't bother you with merges you already did.

Just for completeness, note that you don't have to do it this way - i.e.
with lots of merging back and forth, although Berend is correct,
Perforce is *very good* at handling merging, especially in both
directions.

You can have the _exact same_ versioned files checked out into multiple
project workspaces without any branching or merging - just workspace
mappings. Then, _any changes_ committed to those shared files are
changing those files for _all projects_ with no merging back and forth
necessary. 

That may not be the model you desire however as the branch and merge
model does provide more change isolation. Perforce supports both ways of
working, essentially.

TTFN,
  Paul.