Does anyone have any pointers on how to properly place Dynamic C projects under version control? The LIB.DIR file is the main problem. By default it and the LIB directory exist in the Dynamic C installation directory, I can’t guarantee that every programmer has the same installation directory.
I’m trying to maintain multiple projects in subversion repositories. So far, my plan is to have a custom LIB.DIR file for each project that exists in the repository. Next I plan on having the main LIB directory under version control as well, so that it will be checked out along with the working copy of the firmware project.
Does anyone else know of a better way to do this? It seems as though Dynamic C is really not designed to work well with a version control system. Absolute paths are really hurtful in these circumstances.
Well, it’s been a year since I originally posted the above question, and I can only assume that there is either no answer, or that I’m the only one who uses source control!!
So after all my experiences dealing with source control (mainly subversion) and Dynamic C, here are my recommendations to Rabbit on how to update their software to work friendly with source control:
Allow a per-project lib.dir with relative paths. The global lib.dir should probably use relative paths as well, but the project lib.dir MUST allow relative paths to project libraries. The global libs should NOT be included in the project lib.dir, as each user may have installed DC in a different location.
Separate the .dcp file into a project configuration file, and a user configuration file. User preferences (such as window locations) do NOT belong in a project definition file. This way, the user config file can be ‘ignored’ and never checked in to source control. As it stands, if I move a window or close a .lib file in DC, any source control will register that as a change in the main project file. This is bad.
Hopefully someone from Rabbit reads these forums, as I don’t believe my support account is still active.
