[p4] Mapping of development setup files

[Jeff A. Bowles]

I suspect that the second-workspace strategy is easier to debug, safer, and
limits the scope of "surprises" for files that aren't part of the
development/compiler environment.

   -Jeff Bowles

On 9/28/07, todd.benham at kodak.com <todd.benham at kodak.com> wrote:
>
> Thanks for the tip.
>
> I tried this with null and at first it appeared to be working but I
> couldn't see the second mapping.
>
> I tried this with null and two separate mapping one with c: and one with
> i:. When I tried this, it crashed p4v.
>
> I went back to just c:\ and then I couldn't see either path in the
> workspace view. The workspace view in p4v is just blank (tried refresh,
> etc.). I attempted a sync but I am, so far, uncertain if that worked
> correctly. But without being able to view the workspace I am thinking this
> not the best solution for me.
>
> Perhaps, the second workspace will be the answer.
>
> Todd
>
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of G Barthelemy
> Sent: Friday, September 28, 2007 11:27 AM
> To: Todd D. Benham
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Mapping of development setup files
>
>
> On Unix, you could use symlinks at filesystem level, unfortunately
> Windows doesn't have that option (bar junctions, but they're not as
> flexible).
>
> I reckon this is why Perforce has provided this capability for Windows
> only clients:
>
> - set your client Root to "null":
> Root:       null
>
> - and your workspace view to point to the directories you want:
>
> //depot/project/whatever/... //todd_client/c:/ws_todd/...
> //depot/project/compiler/inc/... //todd_client/c:/compiler/inc/...
> //depot/project/rtos/inc/... //todd_client/c:/rtos/inc/...
>
> This should work fine.
>
> Guillaume
>
>
> On 9/28/07, todd.benham at kodak.com <todd.benham at kodak.com> wrote:
> > We have several cases where files need to be modified and tracking in
> > version control and then mapped outside the typical workspaces.
> >
> > Say a typical workspace root is
> >
> > c:\ws_todd\
> >
> > Not we have certain compilers and other OS files that are modified from
> > the original install. We only track the one that changed from the
> > original. In VSS, we simply mapped these (by overriding the default
> > location) to the right locations and developer would sync those on a
> daily
> > basis (even though they rarely changed).
> >
> > These kind of files might be in a directories such as
> >
> > c:\compiler\inc
> > c:\rtos\inc
> >
> > As best I can tell, this is impossible to map in one perforce workspace
> > (unless root is c:\ which is highly discouraged).
> >
> > My current solution would be to
> >
> > 1) Create a script that uses filespecs and p4 sync to map the
> appropriate
> > files from a somewhat arbitrary location in the depot.
> >
> > 2) Another thought is to have a second workspace that could be sync'd
> when
> > the development environment is set up or something changes.
> >
> > In each case, it becomes a multi-step process and potentially error
> prone
> > if forgot. This is not too bad since we have automated builds so a least
> > the that can enforce the 2 steps.
> >
> > Does anyone have other suggestions?
> >
> > Todd
> >
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com