Pull/Push to different Parent Branches

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/10/2012 5:05 AM, WhisperingChaos wrote:
> New question #202702 on Bazaar:
> https://answers.launchpad.net/bzr/+question/202702
>
> This is what I'd like to do: I want to expose a main trunk that
> provides a "tip" with the most recent and successfully compiled
> content. However, I wish to protect the main trunk from dispensing
> problematic content to developers by first running a compile and
> associated regression tests before the changed content is committed
> to the main trunk.
>
> The feature mentioned above could be implemented by creating a
> parallel trunk (another branch) that accepts developer changes
> (pushes). Once the changes have been verified, the content would
> always be pushed (never merged) from the parallel trunk into the
> main one.
>
> To determine the feasibility of the above, a simple simulation was
> constructed using a bzr shared repository. The shared repository
> was created with the following branches: a main trunk, a parallel
> trunk, and a developer's branch. I used bzr explorer and set the
> pull parent to the main trunk and the push parent to the parallel
> trunk. Afterwards, the contents of the main branch were pulled to
> the developer's branch. The developer's branch was then updated,
> committed, and then pushed to the parallel branch. Finally, the
> parallel branch was pushed to the main trunk. All worked as
> expected for this simple case, however, I'm just wondering if
> there's some reason to be concerned about this configuration.
> Also, is there known and better implementation for the feature
> outlined above.
>
> Thanks!
>

This would probably work at doing what you requested. You would pull
and push to the associated branches. You'd probably want to try to set
permissions so that trunk is readonly to everyone but the bot.

However, under this pattern you make it difficult to have more than
one person doing any development at the same time.

Specifically, Imagine:

1) John pulls trunk, at rev 10
2) Chaos pulls trunk, at rev 10
3) John commits a small patch, rev 11, and pushes it up to 'parallel'
4) Chaos works on a larger patch, and completes it.

At this point, Chaos cannot commit and push to parallel, because it
has already diverged from his work.

He could:
1) Pull from parallel (before he commits), or merge from parallel
after. However, this brings in the 'unsure' revision 11. Which means
he still has to build his change above a revision which may not make
it to trunk.

Imagine for example, John's 11 was broken, if Chaos merges or pulls
it, his branch will be broken.

2) Push to a different branch, and the bot will merge those branches
to trunk if it passes the test suite.

(2) still allows each change to pass the test suite before it lands on
trunk. However, it means that you don't artificially serialize or
inject dependencies between revisions until they are committed to trunk.

(Note there is both http://launchpad.net/pqm and
http://launchpad.net/tarmac that are bots meant to help out with this
sort of work.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/8D2QACgkQJdeBCYSNAAOSJwCgoirG9G/eyUBBK/K/ChrjPf8q
mpYAn2McDgkI41NSZBpe4buh/M+lGhym
=x28e
-----END PGP SIGNATURE-----