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

| 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.

 I don't believe that allowing people to use BK to pull changes without
their nominal dependencies affects this. You're not changing existing
repository history; you're just adding a new changeset in a way that's
more convenient (and more inside the VCS, and allows more information
to be preserved) than generating a patch using the other repository and
feeding it in by hand (or script).

 If you then later merge between the two repositories you will have
a situation where the same change appears in two different changesets
(and causes you some degree of merge heartburn) -- but again this is
no different than the existing situation if one uses patches, plus
the VCS has a chance to do better since it knows more.

 If you have a requirement that all (master) repository checkins or
state snapshots have to pass testing, then that requirement exists
regardless of how the change arrived in the repository: pull, merge,
edited a file, applied a patch, imported an out-of-sequence changeset,
whatever. I don't believe that adding another way to generate a new
changeset makes the situation any different.

        - cks