Re: Suggestion

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
Received on 2014-07-09 15:33:05 CEST