Version control of deliverables

Question

We need to regularly synchronize many dozens of binary files (project executables and DLLs) between many developers at several different locations, so that every developer has an up to date environment to build and test at. Due to nature of the project, updates must be done often and on-demand (overnight updates are not sufficient). This is not pretty, but we are stuck with it for a time.

We settled on using a regular version (source) control system: put everything into it as binary files, get-latest before testing and check-in updated DLL after testing.

It works fine, but a version control client has a lot of features which don't make sense for us and people occasionally get confused.

Are there any tools better suited for the task? Or may be a completely different approach?

Update:

I need to clarify that it's not a tightly integrated project - more like extensible system with a heap of "plugins", including thrid-party ones. We need to make sure those modules-plugins works nicely with recent versions of each other and the core. Centralised build as was suggested was considered initially, but it's not an option.

Answer 1

I'd probably take a look at rsync.

Just create a .CMD file that contains the call to rsync with all the correct parameters and let people call that. rsync is very smart in deciding what part of files need to be transferred, so it'll be very fast even when large files are involved.

What rsync doesn't do though is conflict resolution (or even detection), but in the scenario you described it's more like reading from a central place which is what rsync is designed to handle.

Answer 2

You should look into continuous integration and having some kind of centralised build process. I can only imagine the kind of hell you're going through with your current approach.

Obviously that doesn't help with the keeping your local files in sync, but I think you have bigger problems with your process.

Answer 3

What about embedding a 'what' string in the executables and libraries. Then you can synchronise the desired list of versions with a manifest.

We tend to use CVS id strings as a part of the what string.

const char cvsid[] = "@(#)INETOPS_filter_ip_$Revision: 1.9 $";

Entering the command

what filter_ip | grep INETOPS

returns

INETOPS_filter_ip_$Revision: 1.9 $

We do this for all deliverables so we can see if the versions in a bundle of libraries and executables match the list in a associated manifest.

HTH.

cheers,

Rob

Answer 4

Subversion handles binary files really well, is pretty fast, and scriptable. VisualSVN and TortoiseSVN make dealing with Subversion very easy too.

You could set up a folder that's checked out from Subversion with all your binary files (that all developers can push and update to) then just type "svn update" at the command line, or use TortoiseSVN: right click on the folder, click "SVN Update" and it'll update all the files and tell you what's changed.

Answer 5

Building the project should be a centralized process in order to allow for better control soon your solution will be caos in the long run. Anyway here is what I'd do.

• Create the usual repositories for source files, resources, documentation, etc for each project.
• Create a repository for resources. There will be the latest binary versions for each project as well as any required resources, files, etc. Keep a good folder structure for each project so developers can "reference" the files directly.
• Create a repository for final buidls which will hold the actual stable release. This will get the stable files, done in an automatic way (if possible) from the checked in sources. This will hold the real product, the real version for integration testing and so on.

While far from being perfect you'll be able to define well established protocols. Check in your latest dll here, generate the "real" versión from latest source here.

Answer 6

Another option is unison