Question

Background: This pertains specifically to building DLLs to extend AutoCAD. Every 3 years they change the binary compatibility, generally also changing the version of the .NET framework they compile it on. Sometimes they also change method signatures, DLL entry points and add/remove functions.

This means that I need to maintain different Project settings, references (Visual Studio project files), perhaps compiler preprocessor directives to build different versions of the same plugin from, essentially, the same code. As of now I need 3-6 different versions, depending on what methods I call. Generally 3 is enough. ... oh, and there's 64-bit in recent versions but that shouldn't be a problem if I build for "any cpu".

The core development process (Parent) would be against the latest version. When that is ready for a release I would build all the different versions for that release. All of the different versions would pull the code from the latest (core) version.

I will (probably) build each version on a specific machine with all of the versions on it. Just for kicks, I may also set up a separate VMs, specific to each version of AutoCAD for testing.

In either case, I would like to make this as easy as pulling the appropriate repo, building it, running the unit tests and trying it out in debug mode. If there is a problem in a specific release I may modify the code a little, perhaps with compiler directives and push that back to the core repo.

I saw this question but I'm note sure if it helps me since I have no intention of merging the separate branches / repos back together.

This question is probably the closest to answering my question but it also relates to ultimately merging everything back together of one build.

Question(s): What is the best way to maintain the specific-version build repos in sync, apart from the project configs, references etc. My initial thought was named branches but Kiln warns against those.

Is there a way to keep the repos in sync on the Kiln website or is it a better idea to simply pull-push the code locally at release-build time? -EDIT- Duh, the In / Out tab for the repo on the Kiln site..

I can see that maintaining the project file references is going to be the tricky bit. This is really the crux of my question. How to maintain the version-specific parts of the VS project file while incorporating code changes, adding, deleting files etc.

Any workflow suggestions for this are more than welcome.

Answer 1

First of all, don't be afraid to use named branches. They work just fine in Kiln. We have been doing this for almost a year, and it is working very well.

That being said, I don't think any of the Kiln or Mercurial branching techniques can solve your problem. In your situation, you have multiple versions that need to retain some unique attributes while sharing others. If each version was a branch, regardless of the flavor, you would need to "cherry pick" individual changesets and transport them between branches rather merging entire branch histories. This is not something that Mercurial does well. You might be able to work something out using queues and patches, but most of my reading shows people abandoning that route fairly quickly once they try it.

A more workable option might just be to create separate directories with separate solutions and projects for each product version. These solutions could all refer to the same set of source code files, but retain individual compilation and reference information. In the case of extreme compatibility issues, you could, for example, create a 64 bit version of the code and only reference it from your 64 bit solutions.

With your product versions separated by directory, you could use named branches in a much more productive branch-per-feature workflow.

Answer 2

I would be looking at writing a tool to generate all the project files you need based on a set of templates for each config. All files in a directory could be added by default to the project file for that directory. (project files are just XML at the end of the day)

Each set of project files could output to a different folder. Then generate a solution file for each config that has all the project files for the config in it.

(Thinking about it a bit more, you tool could just update the file of files in the project file, and therefore use a project file as its own template, if you don’t have many projects)

With just a few #ifdef in your source code you should then be able to avoid branching at all.

(This is how it used to be done 20 years ago when most apps had to work on 101 different version of unix, all that needed different compile flags but only a few changes to the code between them)