Les Mikesell <lesmikesell_at_gmail.com> wrote on 08/14/2013 01:58:29 PM:
> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: dlellis_at_rockwellcollins.com
> Cc: kmradke_at_rockwellcollins.com, Ben Reser <breser_at_apache.org>, Ivan
> Zhakov <ivan_at_visualsvn.com>, Johan Corveleyn <jcorvel_at_gmail.com>,
> "users_at_subversion.apache.org" <users_at_subversion.apache.org>
> Date: 08/14/2013 01:58 PM
> Subject: Re: How to change paths on an external file without a full
> update --depth infinity?
> On Wed, Aug 14, 2013 at 2:04 PM, <dlellis_at_rockwellcollins.com> wrote:
> >> Designing a build
> >> management system on top of subversion using only externals
> >> is risky.
> > I disagree, but we've had this conversation already. I'd be very
> > try anything to help our performance.
> Externals can be very useful to assemble mixed revisions of
> separately-versioned components, but why do they have to be
> file-level? Are there other tools involved in the process that do not
> understand subdirectories or symlinks? Or just no natural groupings?
No natural groupings. In embedded, safety critical DO-178b products, we
have very rigorous rules that essentially prevent one size fits all
developments. Product line management on things like this become very
hard and tend to create clone and owns of the code base as we move from
one system to another. Requirements and verification (including
structural coverage testing) is a beast.
We did a study of similar projects and found that in unexpected amount of
code is common that one wouldn't expect to be common. This ad hoc common
code was larger than the amount we could actually purposely create as
"designed for reuse" (libraries or directory level commonality). I'd
imagine if anyone took a baseline and forked it, did a bunch of work and
compared it back to the baseline, you'd be surprised what turns out as
still being common (unless someone does a ton of style changes). Now try
and imagine how to extract those random bits of code into groupings. It
can be done, but in our world, you can't go off and willy nilly change and
refactor code. Its nice to maintain a living pedigree with your baseline.
Now, in our case, we do stuff for aircraft,... wouldn't it be nice to
maintain living pedigrees with all similar models of aircraft? Fix an
issue in one place and advertise it to all the others. File externals
give you this. It fits very well into the embedded safety critical world
in the "don't touch that code unless you have to" and "let's fix it once".
Refactoring code in this world just can't happen as often as you'd like
(its also a chance to reinject bugs).
Hope this helps!
Received on 2013-08-14 23:23:49 CEST