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.
I could go on, but hopefully, the thrust of my concerns is clear at
this point. I simply cannot conceive of a sound argument for having
developers synchronize their feature branches to the latest release
rather than the trunk. When I asked someone defending the proposal
what the harm would be in having developers create their feature
branches from the trunk, the response was that this could be chaotic
because the trunk is less stable than the latest release. While this
is certainly true, the fact is that the trunk changes will have to be
taken into account by the individual developers at some point, and it
seems to me that the "sooner rather than later" approach would tend to
minimize the chaos and wasted effort. As I see it, a strategy that has
a single integrator integrating changesets from multiple developers
who never synchronize to the trunk (not even when they create their
branches) would be not only chaotic, but practically unworkable.
Am I missing something here? Are there any real-world paradigms in
which subversion feature branches are synchronized to the latest
release instead of the trunk?
Thanks,
Brett
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1318902
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-15 17:38:47 CET