Brett: See below.
> -----Original Message-----
> From: Tyler [mailto:tyler_at_cryptio.net]
> 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.
This is a huge advantage for you. A team which is willing to invest some
time in thinking about these issues before diving in is very smart.
>
> 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
I'm nowhere near expert on SVN, but my team has recently wrestled with
similar issues. It sounds as though the point above is the critical one to
understand. What are the reasons why developers want to avoid starting from
the trunk?
> > 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.
If I'm following you correctly, this will risk significant loss of features.
Every time new changes are merged into the trunk, the only protection
against losing previous changes is a complicated manual merge by the
integrator. And I agree with you that whatever testing has been done by the
developers will be wasted. The code from the developer's branch will not be
traceable to the trunk. Therefore any test results from a development
branch would be suspect in the eyes of an auditor. I'm assuming here that
you will have your code reviewed by outside parties, such as customers,
quality system auditors, etc.
Proving the provenance of the code will probably come down to trusting
someone's word: "Trust me, I took that code from release X." But as you've
described it, SVN won't be able to prove that assertion -- at least not
without some effort.
Another issue to understand is why it is important to begin development from
the latest release, and not from the latest development HEAD, on the trunk.
Here's an example: I've dealt with a customer who wanted us to prove that
version 2 of some code actually started from the version 1 code base. The
customer actually wanted to send us the old code before we began work, and
have changes made on the "official" code base. Indeed they were quite
insistent about it. A little dialogue uncovered the reason why. The
customer needed to prove the lineage of new releases from previous ones.
Their solution was to send the code, but a better one was to use Subversion.
SVN could prove that version 2 was traceable directly from version 1, via
diffs and change history. The real need was satisfied.
If there is a hard business requirement for the proposed plan, then you
won't be able to adopt the "Subversion Way". But the stated need might not
be the real need. There might be other needs that no one has thought of.
The proposed solution might not be the only one.
Obviously, as you've posted, if the trunk can be used for the "latest
release", then the very convenient Subversion model can be used and you'll
see the benefits you've identified.
Good luck, and I hope this helps.
Erik
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1342543
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 18:58:28 CET