Good Diff, Merge and Version Control solution with FoxBin2Prg 1

[dantheinfoman]

Hi All,

I've got SourceTree and I'm trying to get FoxBin2Prg to merge 2 different versions of an .SC2 file. It butchered the form, rendering it inoperable. Maybe I don't know how to merge right, or maybe SourceTree isn't as good as Plastic SCM like in this video:

https://www.youtube.com/watch?v=sE4wQ50Itqg&feature=youtu.be

. My only problem with this is that Plastic SCM isn't free like SourceTree is and it seems like they should both work. I don't know.

But surely all you brilliant FoxPro teams are using some sort of version control, possibly being able to work on the same binary files (vcx, scx, etc) at the same time and then merge together, right? I'm not just imagining this.

I'm trying to get my team out of the dark ages (using a word doc to version control and 'checking out' files by typing them in there). Please help me understand the best solution for version control and merging binary files.

Thanks a million for any suggestions.

Dan

 

[fdbozzo69]

Hi Olaf:

I may help you with TFS + VFP + FoxBin2Prg if you want.

I just use TFS for uploading to VFPx, because it's needed by VFPx, but for my development I use PlasticSCM.

Just in case this could give you some idea of using with TFS, in the screenshot you posted for configuring SccTextX for convertion (by the way, SccTextX does not regenerate binaries!, i've made some contributions to it), you can configure FoxBin2Prg.EXE in the same way, but would need to configure the SourceSafe support for the extensions (just indicating that FoxBin2Prg do use *.??a text files and not the default *.??2 text files)

Obviously, you could use TFS without VFP integration, as I use for uploading to VFPx site.

One important thing to remember is this:

A) For checking-in: Text files of all modified binaries must be regenerated. If a text file is not generated (FoxBin2Prg just replace text files if they have code-changes) then that means that the binary have no code-changes (only changed it's internal compilation p-code or some timestamp, but not the real code), so it can be reverted. This way, before checkin-in you revert all binaries that have no really code-changes, and as result the checkin is minimal.

B) For merging: Because the merge is done for two branches that are already checked-in, the conflicts are resolved on their text versions and the binaries are regenerated from this text versions. In example, SourceSafe handles this automatically with FoxBin2Prg, because I've implemented the return codes to be compatible with it, and to answer to the SCC API that "bidirectional support is active" (SourceSafe answers "just text conversion"), so once you resolve the conflicts merging the text files, SourceSafe regenerates the binaries automatically. I suppose that with TFS is something similar, but I didn't tested.

As I said, I've used TFS just for upload (have it installed in a VM machine with Win7), but if you are interested in integrating with FoxBin2Prg, then contact me by email so we can do some testing and exchenge some feedback.


Fernando D. Bozzo

 

[Olaf Doschke]

Thanks Fernando,

that's a generous offer. I may contact you when I'm more idle than currently, but this will be something to discuss with this customer, as it's needing extra steps and as I quit working for them this would need their attention to be able to work with such repositories after I'm gone.

My situation of only having VFP+VS+TFS (IDE and Source Control) at my own workbook or VFP+SQL Server+Company Databases (IDE, Database Server and test data for running/debugging within the IDE) in a VM is making the whole process unwieldy. Even if there would be a perfect VFP+Source Control integration I could not use that, as I have to copy the whole project to the VFP+data VM, you can forget to automatically check out files or automatically add new files to source control. The VM I develop on has no TFS connection, so I'm not only stuck because of VFPs old ways of source control.

I've written a small compare tool myself ending up in a browse of a file list needing updates or being new. I have even stopped using that tool, as it's tedious to only check out these files for checking in the changes, if the IDE doesn't do that automatically. So I do miss some automatisms better than the old MSSCCI Provider API 1.0, but still working from within the IDE. Then I could think of extracting amd anonymising or generating test data on my workbook to fill that gap of data access.

At least one thing is working quite nice in conjunction with Visual Studios Source Control Explorer used as TFS client: I just right click on the main project folder and say add items, and it lists all files currently not in source control, so I can add new things easily without forgetting something.

The way my situation is I only rarely take the time to copy back my VM work to my own main workbook to overwrite the checked out sources, add new items and commit that.

May main pain is not TFS, but having no real developer workstation with IDE+Source Control+Data in one place.

Bye, Olaf.