SmartQuant Discussion

I would like to get the code I build in OpenQuant into a Version Control System for many reasons.

Has anyone done this so far? I would like to use something that is open source (ideally) but am not opposed to paying for a product. I am considering Tortoise SVN (http://tortoisesvn.tigris.org/) & ankhsvn (http://ankhsvn.open.collab.net/servlets ... eID=PpvZJl)

Does anyone have any recommendations for a product?

Thanks,
Eric

I use TortoiseSVN and subversion, and they work ok.

The main problem to solve is how to separate your code from the OQ code files, since the OQ design forces all of your code files into the same directory space as their files. This is not an optimal software design for sure, because it makes version control more of a headache. IMHO, OQ should provide a user base directory to parallel the OpenQuant 2 directory in the Docs & Settings tree, but let users specify the location of the directory (eg in a visible directory outside of the Docs&Settings tree).

In the end I only put my own files into version control, and then (using svn) checked them out over top of the OQ 2 directory in the D&S tree. If you check in the OQ files, then you run into a bunch of vendor file update issues.

Hey kkkwj,

Do you still do that? I'm having the same issue I think, please see here: viewtopic.php?f=60&t=6686&p=32871#p32871
I have my own solution in VS and various projects more or less related to OQ... In one of them ("OQStrategies"), I have added code.cs of my strategies as well as OQ script files, but added "as a link". So VisualSVN complains that they are not in the same directory... and therefore I can't commit them in the repo. First thing I try was to put my solution's folder in the OpenQuant (in users's document folder...), and set the working copy path to be the OpenQuant directory but it became complicated. Any solution? Is the issue clear?

Thanks!

Hi All,

Yes, I still use subversion with OQ. I think it's the easiest solution, and has a good Collabnet free server and GUI TortoiseSVN client for windows. It's plenty powerful enough for local OQ development, I think. Apparently Git is the latest opensource version system, but I won't be switching to it any time soon for the limited things I need to do (check in/out on multiple machines on my home network).

I will reiterate (apologies to the OQ guys) that the biggest, constant headache of doing version control with OQ is that your strategy code files (eg, code.cs) are _forced_ into the same folder as the OQ distribution files. This is a big headache because then you're constantly having to manually separate Anton's OQ files from your own files whenever you want to do checkins.

Personally I find it to be a constant irritant, and knowing that it would be so easy for the excellent OQ programmers to put in a fix (I've described the required changes in detail to them before) makes it even more frustrating. To summarize, OQ needs to implement a set of simple set of search rules to pick up code files when it is constructing the list of files to inspect. Currently OQ searches ONLY in the distribution user files directory where all the example solutions/projects/code files are stored. Instead, it should also search in one or more user defined folder pathname locations where I can store my own solutions, projects, and files. The final list that OQ would work with would be identical in structure to the OQ code, so no core OQ would need changing -- only the core list construction code, and the file saving code (to use the original pathname of the file) would have to change, plus a couple of options for specifying the user-defined folder paths.

But since the fix hasn't happened in many years, all I can say is how I try to work around it. Every time OQ is upgraded, you have to check in the distribution files, and then somehow check out your code files on top of the new distribution directory. If you just copy in your files, you lose your complete checkin history by making them newly checked in files. So if I remember correctly, I install the new OQ release, copy out the new distribution files, check out my latest checked in copy (including all the previous distribution files), then copy back in the latest distribution files, and then manually reconcile the differences between the new and old distribution files, by checking in, marking as new, etc the distribution files until they are all checked in.

At that point, the directory is once again in sync with the repository, and you can start working again. Rebuild all projects, and ignore or checkin anything to do with the distribution files. Eventually you'll get to a place where your own file modifications will show up as changed, but the distribution files will not (they'll still be polluting the list of files that you have to troll through on each checkin, but at least you'll be able to check in files).

If you have to check out your files on a different machine, then you have to go through the whole reconciliation process again, because a checkout will propagate all the distribution files as well (sigh).

Contrast that whole process with the case where only your own files were in a separate directory. Upgrade OQ, or downgrade it, at will. No impact at all on your own code files. Check out your own files to a new machine -- no impact at all on the installed OQ distribution files, regardless of OQ version. Complete independence as far as filenames, locations, etc are concerned (internal code changes might not work between OQ versions, obviously).

I hope this helps. I should put all this in one of the OQ user docs one day. (I was hoping Anton would implement the changes before I spent the time to write all this stuff up with examples, etc, but other priorities prevented the fixes from getting on the product dev path, so I never got around to investing the time to document everything, etc.... you know the usual software feature development life of schedules etc... Good luck.