Imagine that you develop a large Matlab program, which uses hundrets of functions. To keep the different modules independent from eachother, the corresponding functions are store in separate folders, e.g.:
project1\gui\ project1\calculations\ project1\export\
During the development your create different version of e.g. the GUI and the export functions and get this hierarchy:
project1\gui1.01\ project1\gui1.02\ project1\calculations\ project1\export1.01\ project1\export1.02\ project1\export1.03\
Which tools are you using (do you recommend) to manage these folders in your MATLAB path? Do your tools consider dependencies, e.g. export1.03\ needs gui1.02\ or higher?
Due to the different folders GENPATH does not match. If you're working on project2\, project3\, etc., using the PATHTOOL and storing the different path strings does not work also, because the versions of the different projects cannot be set independently.
I've written a tool for this job, but it is far too specific and complex to be published. In addition it includes folders of the compiled MEX files for the different Matlab versions and patchs of the toolbox functions (e.g. a TYPECAST and BSXFUN for Matlab 6.5). Using a standard source control system helps to manage the files, but I did not find a comfortable method to care about the set of folders in the MATLAB path. Some of my projects are used for clinical studies and the users must be able to reproduce the results for 10 years after a publication. "Sorry, I cannot get my old source control system to run under Window 14" is not an option.
I think this is a common problem and therefore I'm interested in your solutions.
No products are associated with this question.
In my MyStartup.m I have a call to a function LOADPROJECTS that lets me choose projects, then the paths required gets added to the matlab path. To my LOADPROJECTS I also have EDITPROJECTS, ADDPROJECTS, etc. So I can set up the paths for Project6p5 then unset and set the paths for Project7p2p.
Maybe you're asking for something more extensive, but this covers my current needs to keep separate versions apart. I'd be very interested in hearing what others do.
interesting question. And there will be no definite answer ;-). I can only describe my approach:
I'm also curious what others say.
Your folder naming does not seem to fully capture the power of modern version control systems. If you think of your project as having a version and not the individual components, then you will never have to have folders like gui1.01.
My projects tend to rely on a set of common export and calculations folders. These I version control separately. When I start a new project I import the most recent version of my calculations "project." In this way each project has its own stable copy of the calculations project.
I manage a similar issue with a product I maintain that uses a lot of common in-house tools that are also used by some unrelated analysis functions. The product and analysis code are kept in separate git repositories. I have packaging & release functions checked in with the product that I use to create reproducible builds for delivery; they wrap a call to git that determines the version number from the latest tag (git describe), build documentation with the version number embedded, run MCC, zip and copy files to a folder for burning to a CD. The product itself looks for git when not isdeployed, and self-reports the current commit ID when running from MATLAB. (It also compares the data files we ship to precomputed MD5 hashes, because we have to worry about "power users" overwriting data files and producing untraceable results.)
I am planning to migrate the shared functionality to separate repositories and use git subtree to bring them in to each repository that needs the functionality. This way, analysis functions will not depend on the product directory. Once that is complete, I will have duplication between the repositories, but there will be no run-time dependencies between them. Changes to the common functions will be propagated between the repositories only on request, so there will not be any surprise updates.
Using a version control system is only part of the answer. You need to also have a release process to produce the finished software package and a means of setting your environment appropriately to run only the files of that release.
One approach could be as simple as copying the files for the "released" project1 and then having a file that sets this environment correctly. Then, project1 is effectively "frozen" in time and you can return to it at any point in the future (*). Of course, in a modern version control system, you can also add in branches, tags, etc to know when each was released and also use it as a means to re-create and patch older versions as needed.
You should also take into account other dependencies you have -- for example, compilers, web servers, drivers and other software bits you might need to re-create the environment at release time. Depending on the complexity and number of interactions in the various software modules, the communatorics of testing changes for past versions may make trying to keep up what version works with what other version to be too complex an undertaking -- for example, if you make a change to package A that's at version 1.0.2 and that is supposed to be compatible with three old releases, you need to test all of those to make sure they still work, give desired outputs, fail in the same way and so on. This can be daunting depending on the size and complexity of your code base.
And, of course, you also need to actually test your releases in a "sterile" environment to ensure that you don't have some dependency that you didn't capture.