--- "Jeff A. Bowles" <jab at piccoloeng.com> wrote:

I suppose the question is: Are you looking for su-fficient or e-fficient? *Could* you branch in the one-off scenario I described and use a change-number to represent that release? I suppose so -- but what would be the advantage? Just so you could always use change-numbers to represent releases? Sorry, but that's just not a big enough win to merit all the extra work involved in creating the branch, having to work with that branch (dealing with client-specs and all that), then migrating the changes from that branch back into the release branch that the changes were destined to go into in the first place (and by then, the files involved in the one-off may well have gone through other changes on the release branch, so now you've got resolve issues). It's far easier, and impacts far fewer people and takes far less time, for the build engineer to simply put together a client based on the original release, hand-pick the changes the one-off customer wants, label it and release it to them, and bang you're done. If you branch for it, you're just creating more work for the build engineer, and for the developer, who will have to deal with all kinds of extra crud that there's just no need to put them through. Of course, if the files involved have been changed (the "sandwiched" thing someone else posted), then you probably will have to deal with branching. But if there's no actual need to, and the only reason you would is just so you could do the change-number thing, it just seems silly to me -- and if you've established a policy that releases are represented by change numbers, then you've boxed yourself into a "branching corner" that I just can't see any justification for -- whereas, if your policy is that releases are labelled, then you've got all the flexibility you need, you can branch when you need to, or not when you don't.

Diane

===== (holtdl at yahoo.com)