[p4] One set of Codebase for 2 versions of the app

Stephen Vance steve at vance.com
Tue Oct 18 04:43:08 PDT 2005

When you branch, you create a work area in the depot in a different 
depot directory from the source. Typically, you will also create a 
new workspace in a different directory location on your disk. You 
don't manage both source bases from the same directory as the original.

Unfortunately, it's somewhat difficult to maintain parallel changes 
in binary files. If you have a tool that does diffs and merges for 
that particular file type, you can add it into P4Win as a handler for 
those extensions.


At 01:31 AM 10/17/2005, Bhavbhuti Nathwani wrote:
>Hi all
>I will try to put into words my thoughts as much clearly as I can.
>Please bear with me.
>I have a project in the folder c:\vso2\sw\a09 which is already under
>Perforce.  Please note this is a FoxPro for DOS app. so I do not have
>integrated support of Perforce and I have to do it manually using
>P4Win (mostly) and command line options.  Most of the files are screen
>files which in FPD are composed of an .SCX, .SCT and .SPR files per
>screen.  .SPR files are the text (.PRG) representation of the modified
>binary files .SCX & .SCT and I regularly check .SPR for diff purposes.
>Now I have a request of a custom app based on this app.  I will have
>to add new codes to the project and I will definately have to have 2
>diff. versions of some, mostly binary, code files.  There still will
>remain a lot of common files.  I know there is a branching facility in
>Perforce which I have never used.
>What I cannot comprehend is how can I manage this from the same folder
>c:\vso2\sw\a09?  If so, what all steps I have to perform before I can
>get to use either version of my app for further development.
>If such diff. versions have to be in diff. folders then how can I make
>a common change in one version that will automatically reflect in the
>other version?
>Many of the future changes I will have to have in both the versions
>and some that will effect only one of the 2 versions.  Some
>modifications will be to common named files between the 2 version but
>will remain modified for each version seperately and should not
>disturb the other version.  Maybe there will be a change that will
>effect in parts to either versions and partly in common.
>I am sure such situations would have been experienced by you all, but
>hopefully I have worded the above right to convey them to you all.
>perforce-user mailing list  -  perforce-user at perforce.com

Stephen Vance
mailto:steve at vance.com

More information about the perforce-user mailing list