[p4] mapping 1 area of depot to multiple areas of workspace

[Chris Weiss]

I've not actually tried it, but could you use overlay mapping?
IE:
\\Source\OS1\Private\...   \\Target\OS1\Private\...
\\Source\Common\...       \\Target\OS1\Common\...
\\Source\OS2\Private\...   \\Target\OS2\Private\...
+\\Source\Common\...     \\Target\OS2\Common\...
\\Source\OS3\Private\...   \\Target\OS3\Private\...
+\\Source\Common\...     \\Target\OS3\Common\...

etc... ? The caveat being that only \\Target\OS1\Common can check in
changes to the Common files, it's not pleasant, but it may be the path
of least resistance.

Alternately, you could create a branch of Common for each OS and use
triggers to integrate any checkin to the other branches. We'd done
that once when moving from SGV (which supports aliases) to Perforce -
the integrate script was a nightmare, but it did work.

On 10/12/06, Jeff A. Bowles <jab at pobox.com> wrote:
> I think that the simplest way to do this might be...
>
> ... have a tree called //CDROM/finalimages/... that you branch your releases to.
> You would only branch things to that release from other places in
> Perforce (that's
> a given) and only when it's passed enough quality controls to put it
> onto the handoff.
> (Make a 'named branch spec' for each chunk of things put into that area.)
>
> If you need a file propagated to eight places on the CD
> (//depot/finalimages/OS1/relnotes.txt,
> //depot/finalimages/OS2/relnotes.txt, etc) you can.
>
> That area, //depot/finalimages/..., is what you map to a workspace and
> make the CD from.
>
> Anyhow, it'll do what you're asking for. Better yet, it'll give you
> the history of that tree during all its twists and turns of the
> release process.
>
>    -Jeff Bowles
>
> On 10/12/06, Ivey, William <william_ivey at bmc.com> wrote:
> > > -----Original Message-----
> > > From: perforce-user-bounces at perforce.com
> > > [mailto:perforce-user-bounces at perforce.com]On Behalf Of Edil Cadenas
> > >
> > > Hi David,
> > >
> > > As I have explained to Steve (Vance) earlier, the way our software
> > > release is configured is that some modules have common files/modules.
> > >
> > > Each workspace is an actual representation of the software product
> > > release (directory structure and all).
> >
> > And you can (should) reflect this in Perforce by giving each
> > physical workspace it's own workspace in Perforce. If you do
> > your sync from the command line, it is easy to set up P4CONFIG
> > so your client changes when you enter each local directory.
> > (Easy to provide a script to do the cd and sync operations,
> > too, or just switch clients in the script and be done with it.)
> >
> > -Wm
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> >
>
>
> --
> ---
> Jeff Bowles - jab at piccoloeng.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
-Chris