Re: Re: Maintaining 'stable' and 'development' versionsof a repository (hopeless newbie question)

On 6/20/05, Chris Siebenmann <cks@xxxxxxxxxxxxxxxx> wrote:
> | No-one has suggested that the VCS prevent the code from being broken.
> | This particular issue is about the reproducability of the source base
> | itself, whether it is broken or not.
> 
>  Then I'm not sure I understand the objection to extracting changesets
> from their nominal dependencies. My understanding was that it was
> forbidden exactly because of that: further changesets were held
> to depend on past changesets, and allowing them to be pulled into
> another line of development (or a separate repository) without those
> dependencies would break the codebase.

The dependency may or may not affect functionality or builds or
anything else.  The key point is that testing (yes that!) was done
with a given archive state, and *any* variance in the archive
different than what you tested requires *some* amount of regression
testing.  The issue is that everyone's view of this regression is
different, no matter how supposedly unrelated a pair of changes may
be.  Ultimately, however, if they're in the same archive, they *are*
related, and that is the main reason why you cannot trivially allow
changeset ordering.

What BK explicitly guarantees is that if you acquire a set of test
data for a node in your change graph, that test data will *always* be
valid for that node, no matter what you do to the archive in the
future.  This is critical to my business, and I imagine it is critical
to others as well.

--eric