
Hi,
as seen from previous posts and my own troubles, please comment on the following.
Branching is based on set theory applied to real life. By 'real life' you make your choices on how to apply the theory and stick to it.
Set theory can be explained by theorems and lemmas which are made to defined fixed truths. Perhaps these theorems are too general and complicated and there is a need to limit them when applying them to real life.
Cant you guys just come up with some small set of theorems and lemmas that defines your ideas and language clearly?
Had I understood this stuff as well as you experts I am sure I could give this a good try, and in one way or the other I am sure that you experts do have your 'real life' theorems and lemmas working well for you whether you are aware of it or not. For the
rest of us the future challenges are new and unknown and learning this as you go is not for everyone.
'I just want to be sure' is the big concern for so many, me included, confirms this problem many have. Not all of us have experts in our teams already and hence this problem is real.
Certainly, with the excellent work you already have done, it should be quite possible to do this with a reasonable effort.


Developer
Apr 21, 2010 at 1:34 PM
Edited Apr 23, 2010 at 1:08 PM

I disagree with your basic premise that source code management, specifically branching strategies, are *based* on set theory. My view is that they are based on a common sense approach to understanding the goals, benefits, pros, and cons of using branches
to manage source code. We attempt, in our branching guidance, to express these concepts in simple, clear English rather than set theory.
Set theory is a branch of mathematics, used for studying collections of objects (sets). I suppose you could argue that any collection of objects (people, trees, cars, source code files) could be studied using set theory. But this argument, in my view, does
not support the premise that branching is based on set theory, or that set theorems are the best or even a useful way to understand branching strategies.
I prefer instead, to describe our branching strategy in plain English rather than through a set ofmathematical theorems. I do not wish to set an expectation that one must be a mathematician in order to understand some simple strategies.
I fear that you are making this a much more complicated problem than it really is.
If you have specific concerns or questions you would like us to answer, please post them.
If you would like to volunteer to come up with an initial set of theorems and lemmas, I would be happy to critique them.
Judging from the feedback we have received, there are many, many people who have successfully downloaded the branching guidance and applied it to their reallife problems.
Regards,
Bill Heys
VS ALM Ranger

