What I mean by making changes to higher revisions is the following:

Say the software I am working on has released versions of 1.4 and 1.5. Version 1.6 is in development. A bug is found in 1.4 and is corrected in 1.4. The fix will need to be made to 1.5 and 1.6. Ideally migrating that change to 1.5 and 1.6 should be just integrating the changelist into those versions. But with the classes, reports, and forms being binary files, integration is not possible. I must determine what changed in 1.4 and then make the same changes in 1.5 and 1.6 manually.

I was hoping that someone might know how I would be able to handle this in perforce.

Jason

>Hi Jason
>
>>I am using Perforce source control. At current, if I make a change to a prior revision of an application in either reports, forms, or classes and I have to integrate that change to higer revisions of the application then I have to manually determine the changes and remake the same changes to each level. Is there a way to integrate the changes through the revisions or is this just the way I have to do it for binary files? Is this the way it works for other source control products when using foxpro?
>
>The other source control products convert the vfp binary files to and from text files on the fly as they are checked in and out.
>
>I do not put more than one class in a vcx and I avoid putting more methods on a class than are necessary - as good design and to reduce the chance of multiple programmers stepping on each others' changes.
>
>That also means I seldom need the merging abilities of the source control products. I use them as an elaborate backup and so I can revert changes if I change my mind or make a mistake.
>
>As to making revisions to higher levels, I'm not following you. Don't make a change to a subclass. Make it to the correct level.
>
>Integrating a change to a report shouldn't be hard. You change the report, check it in and it will be integrated into the next release of the app/exe.