(I am deliberately top-posting.)
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
worries?
The only advice I have (without knowing more specifically *why* your
team wants to do things in this weird way) is that developers often
underestimate the importance of investing time and effort to get the
infrastructure right. Revision control is a strange little niche in the
software world (along with its cousins Build Engineering and Release
Management), so sometimes the coders need someone to guide them in
thinking about the consequences of certain policies.
On the plus side, you're learning about this through "an initial draft
proposal", so it sounds like your team is open to input about the plan,
and that you have time to help work out the kinks. Good luck.
hth,
tyler
On Fri, Mar 13, 2009 at 05:19:19PM -0500, Brett Stahlman wrote:
> Hello,
> I'm a member of a team of over a dozen programmers working on an
> embedded software project for the space industry. The decision has
> been made to use subversion, and a working group has formulated the
> initial draft proposal for our development strategy. I am very
> concerned that the proposal reflects an attempt to do things in a
> manner that is highly inefficient and suboptimal, given the subversion
> model, but I'd like to get a sanity check from subversion developers
> (or at least those with more subversion experience and insight than I
> currently have)...
>
> In a nutshell, the proposal that troubles me is as follows...
> Each developer will develop features in his own private branch, which
> he creates, not from the trunk, but from the latest release. When a
> developer is ready to commit his changes, he uses a simulator to
> perform testing on his private branch *without* pulling in changes
> from the trunk. He then tells an integrator that his changes are ready
> to be integrated. The integrator somehow merges the developer's branch
> back into the trunk (presumably without the aid of `svn merge
> --reintegrate', since the branch wasn't created from or synchronized
> to the trunk). Though the details haven't been discussed, I'm assuming
> the integrator would perform a 2 URL merge using the latest release
> and the developer's branch to produce the diff to be applied against
> the trunk. Once the integrator has completed the merge (likely with
> the developer standing over his shoulder, as I would anticipate a
> large number of both semantic and syntactic merge conflicts), the
> newly integrated trunk version is tested on the actual embedded
> target.
>
> I see a number of problems with this approach...
> -It violates the clear and logical "sync before reintegration"
> paradigm for feature development, presented in "Keeping a Branch in
> Sync" in the subversion manual. (The subversion manual recommends that
> developers create their private branches from the trunk, and merge
> trunk changes into their branches at least once just prior to
> re-integration, and possibly on a regular basis during feature
> development.) Attempting to re-integrate without any prior
> synchronization seems to me to be a recipe for unpleasant surprises.
> -As I pointed out above, the integration merge would most likely
> involve a diff between the latest release and the developer's feature
> branch. Since this diff would need to be applied against a trunk that
> includes numerous changes made by other developers since the release,
> messy conflicts are likely. Moreover, the merge difficulty will
> increase with time, as other developers' changes continue to pour into
> the trunk and the developer's own branch becomes more and more out of
> sync.
> -It will require the integrator (who is probably not intimately
> familiar with the feature changes being integrated) to perform what
> could be a very complicated merge. It seems to me that responsibility
> for ensuring that one's changes work properly with the trunk should be
> the responsibility of the developer rather than the integrator.
> -In the (not unlikely) event that recent trunk changes invalidate a
> developer's own changes, the developer will need to redo not only his
> own changes but also the tests he performed prior to the failed
> integration attempt. This has the potential to waste a good bit of the
> developer's time, not to mention the time of the integrator. Would it
> not have been preferable to have the developer find out about the
> incompatible trunk changes before completing his changes and
> performing his own unit tests?
> -In the event that the integration attempt uncovers semantic conflicts
> that can be resolved only by the developer, it is not clear to me what
> the next step would be in the proposed scenario. Presumably, the
> developer would pull in only those trunk changes he needs to get his
> change working. But what if he then decides to start work on a new
> feature prior to the next release? Since he's not supposed to create
> his new branch from the trunk, he would either need to create it from
> the release, then pull in the changes made as part of his previous
> change, or else he would need to keep his old feature branch intact.
> The latter approach would probably be simplest, but what if, for some
> reason, he needed to delete his feature branch and create a fresh one?
> Reconstructing it from the latest release and a set of revisions is
> more complicated than simply copying the trunk.
> -Simulator testing performed by the developer on his private branch
> prior to integration would involve a completely different code base
> than that which is used for the target testing performed on the trunk
> after integration. This seems significantly to compromise the utility
> of the pre-release testing.
Received on 2009-03-17 17:47:44 CET