Couple of general version control questions...

[Stephen J. Turnbull]

Richard B. writes:

 > I'm happy with using Bazaar now, but have a general version control
 > question. I develop in Visual C++ and only commit the source files,
 > Solution/Project files and any other files which cannot be reproduced.
 > 
 > When I commit a fix/improvement, I don't want to include the .exe,
 > .dll and .pdb files, but I do when I make a public release (ie. so I can
 > debug any bug reports from customers). I could add .exe, .dll and .pdb
 > to the exclusion list, but then these files would not be versioned
 > when I make a public release.

Although the exclusion list is normally versioned and thus propagated
across repositories, that very fact implies that you can have varying
exclusion lists in a controlled fashion.  So one workflow that could
work would be to have a dev branch where you do all the day to day
fixing and improving.  In the dev branch the generated files would be
ignored.

When it's time to release, you merge from the dev branch into the
release branch where you don't exclude build products.  Then you build
the release, "bzr add" any new build products, commit the release, and
then transfer the build to the distribution media.

A second possibility would be to use scripts to build, "bzr add" the
build products explicitly, commit, create the media, then "bzr remove"
the build products for the next development cycle.  (In Bazaar, "add"
and "remove" will do what you tell them to do, regardless of the
contents of .bzrignore.)

 > What's the best way of doing this with bazaar ?

I prefer the dev branch/release branch approach, but it will probably
need refinement.  Eg, what happens if you've been doing incremental
builds in the dev branch, and they work, but a from scratch build (or
worse, the test suite) in the release branch bombs?  I'm sure this can
be handled, but a little thought in advance will go a long way in
preserving sanity in your branches.

Best IMPO would be to use colocated branches (multiple branches
sharing one .bzr control directory, which can be switched among
easily), but Bazaar doesn't support them quite yet.  I don't think
looms could be abused for this purpose, although maybe bzr switch
could be used (you'd still need two repos).

 > Or, would it be best practice to always version these files ?

Unlikely.  That would mean that typically big, not-very-diff-able,
files (exe, dll) get committed for every li'l-fix-and-test-build cycle
(unless you do a thorough cleaning before every commit, which is often
undesirable), which will balloon your repo, I suspect.  I'm not an
expert on bzr internals, though, so matters might be more favorable
than that -- get better advice from somebody who knows.

 > I've also read that it's good practice to version compiler, lib, and
 > include files, but these are stored on a different drive to my
 > project/source files, so how can I commit these files with my project
 > files ?

A symbolic link is the obvious answer.  You could also temporarily
copy them into the project (perhaps in a single-file format such as a
zipfile).

However, is it really necessary that they be with your project files?
Why not simply version them in place (ie, on the other drive), and use
the same tag that you use for the project on the build environment?
This would have the advantage that different projects could share the
same repo for the build tools, which would likely be a big space
saving.  Of course you'd need to be careful about the tag names,
including some project identifier in them so that they make sense in
the build tool repo.

Finally, you could just back the tool folder up to DVD and label the
media with that same release tag.