>> I am not an svn expert, nor have I sent code into space (how cool would
>> that be?!) but I think you have valid concerns. Basically, I think your
>> team should have a very good reason for not doing things "the usual
>> way". Have you presented your concerns to the team? What answers did
>> they have? Or are you gathering your ammunition before presenting your
> A bit of both... I did speak up in the group context in which the proposal was presented, and I argued until I was blue in the face with one of the plan proponents after the meeting had adjourned. The problem is that, because there are no recognized Subversion experts in our group, my opinion carries no more weight than that of one who hasn't read the applicable portions of the manual.
> As for the "why" behind the proposed strategy, the only reason given was that the trunk was less stable than the latest release; i.e., pre-integration unit testing notwithstanding, it is possible for bugs to creep into the trunk. The desire is to insulate other developers from such bugs. I see several problems with this line of reasoning...
The case where the proposed branch isolation fits is where different
developers are doing alternative approaches where only one version will
be chosen to go into the next release. Otherwise the longer you put off
merging, the more likely it is that you will waste time with duplicate
work and incompatible changes. And it doesn't make a lot of sense to
spend a lot of time testing separate portions that will be changed later
anyway unless the tests are designed as unit tests for individual modules.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 20:02:50 CET