David Radcliffe wrote:
> Julian,
>
> Thanks for considering my suggestion, and your detailed reply.
>
> Yes, 'sparse branching' does nicely describe the effect I am trying to
> achieve. I do appreciate that any form of 'variants' is going to cause a
> management overhead.
A few more thoughts, on reflection.
1. I should have said, sparse branching is undoubtedly useful. Subversion
currently doesn't have a way to manage sparse branching, except that you can
branch a single sub-tree of your project. The back end allows branching each
file separately, but there is no support for managing that at a higher level.
Adding some sort of sparse branching support, at least per file, is certainly
an interesting direction to contemplate for Subversion in the longer term.
> The specific problems I'm trying to overcome are:
>
> 1. Parameter controlled functionality:
> Fairly easy to achieve,
> Requires only one build (of any 'tag'),
> BUT
> May result in unnecessarily large .EXE or DLL for every customer,
> Checking (at run-time) for a large number of parameters is messy and
> time-consuming, as is the admin of them,
> All code is present in every customer's copy, so un-licenced features
> could be enabled if parameter name is learned.
>
> 2. Conditional Compilation:
> Advantage of only one check-out (per 'tag'),
> Un-compiled code still visible, but greyed-out,
> BUT
> Suffers from developer resistance ('old school' way of doing things),
> Easy to make mistakes when setting values in MS Visual Studio (other
> IDEs
> may handle this better).
>
> It is these last two points which are the biggest barrier, and their effect
> should not be under-estimated.
> I have heard developers say that they would much rather suffer the overhead
> of
> updating several separate branches (with bug-fixes & enhancements), (along
> with all the risks that that approach exposes), rather than risk using
> Conditional Compilation.
2. I am going to hazard a guess that you're using the IDE's "project
configurations" system to select different configurations. (I don't know the
specific terminology MSVS uses, as it's years since I used it, but other IDEs
have the same idea.) This is the system that lets you customise everything
about how the project is built, from choosing the compiler through to choosing
in what colour the comments are displayed (OK maybe not going quite that far
:-).
The trouble with that system, at least on NetBeans IDE which I'm currently
using, is it doesn't have a way to say "the only thing I want to vary between
configurations is this single #define" and it doesn't have a way to easily
check whether everything else is the same or accidentally different between
configurations, or to help you manage that.
Or, if you're not doing that, then maybe you're going into the project settings
and editing one of the #defines, and have to be careful not to accidentally
touch anything else, and then when you check in the project you have to be
careful about whether you check in the change to the project configuration or
not, and if so whether there are any accidental other changes.
Either way, with interfaces like that, yes, it's horribly fragile.
(And I'm assuming you only need to change one #define to select your variant.
If you're having to change multiple definitions or settings, I'd suggest you
first look into reducing that.)
The reaction from devs that they'd rather use branches sounds very much like a
reaction *away* from something bad, rather than necessarily knowing that
branching would be better.
It sounds like what you need is a better interface, one that lets you select a
variant with "one click" without the risk of changing other settings. I'm going
out on a limb here, but would it be possible to script or write a plug-in to
MSVS to add a "variant chooser" control which either edits the single #define
or selects one of the multiple configurations but also checks that everything
is synchronized apart from the #define, or something? In other words, to work
around the issue that the UI is currently making this kind of work flow harder
than it should be?
> Certainly, the two existing methods of variant management lend themselves
> fairly
> well to the situation of fixes needing applying to common-code (thus all
> variants), which I accept that a 'sparse' branch' may impact.
>
> So, by moving the decision on which variant to compile back to the
> source-code
> check-out stage, most of the above failings could possibly be avoided.
> I do acknowledge that this still is not a 'silver bullet' to cure the
> problem of variants - I doubt that there is one - but it might help.
3. "Branching" as managed by a version control system implies the system can
show you the separate streams of development (so, "log" would be able to show
only the changes on one specified branch, for example) and the ability to
extract changes from one branch and merge them to another branch (imagine if
two of your variants are nearly identical and need the same bug fix). No matter
if you don't often want to do such merges, but the ability to have branches
without even a concept of being able to merge between them and track them
separately is not really a concept of branches at all.
If Subversion was to be able to support this kind of "branching" at the
granularity of text hunks, that has profound implications for the way in which
changes are recorded in the repository, especially in merge tracking and log
history tracking. That doesn't now seem at all feasible.
I think these are the kind of issues that define the essential differences
between conditional compilation and branching (whether sparse or not). Only by
considering your needs in relation to these kinds of issues can you really make
the right choice.
Now, if you say variants aren't like regular branching, and don't need separate
tracking, and don't need merging, then what do they have to do with version
control itself, really, fundamentally? If what you want is support for per-hunk
variants but *not* support for merging and separately seeing their histories
with "log", and so on, then I think it boils down to being just a kind of
conditional compilation add-on.
If it's a conditional compilation add-on that you're looking for, with a better
user interface than MSVS provides, then I have to ask, why a
Subversion-specific one? You already have a language-specific method (#define
in the C family of languages) and an IDE-specific one (MSVS project
configurations). Why a Subversion-specific one, if it doesn't interact with
version control features such as branching and merging and logs? Beyond
trivialities like that it's convenient to have it run automatically after
checkout and update, and knowing it'd automatically be available because you
installed Subversion, of course.
I'm not saying it's irrelevant to Subversion, but that it might be more
productive to think of it as a separate tool that would make a good plug-in to
any version control system as well as being useful on its own.
- Julian
> Maybe the question should be put to the SVN community, to see what other
> users
> feel about this?
>
> I haven't had a chance to try implementing anything. If I get time, I might
> try the post-check-out script idea...
>
> Thanks again, Dave Radcliffe
