Advice needed on using branches to solve a particular merging problem

[Andrew]

Suppose a project contains A and B. The project owns and controls A
but B is owned and controlled by Byzantine developers in another
group. A takes periodic source releases from B. Now, the problem is
how to manage local changes that A makes to B, given that the B
developers will never take the fixes on and given that B make numerous
frequent changes that A needs.

The current approach is to blat A's copy of B whenever B makes a
release. This means that whenever A make their own independent fixes
to B those fixes are lost when A takes a fresh release of B.

I am sure that branching can somehow be used to solve this problem but
I am not sure exactly how. Any suggestions?

Regards,

Andrew Marlow

[Jorgen Grahn]

Post by Andrew
Suppose a project contains A and B. The project owns and controls A
but B is owned and controlled by Byzantine developers in another
group. A takes periodic source releases from B. Now, the problem is
how to manage local changes that A makes to B, given that the B
developers will never take the fixes on and given that B make numerous
frequent changes that A needs.
The current approach is to blat A's copy of B whenever B makes a
release.

A wiktionary search for blat gives "to cry, as a calf or sheep" or "to
produce an overrich or overblown sound on a brass instrument". I guess
you meant "blast away", "pave over" or "overwrite"?

Post by Andrew
This means that whenever A make their own independent fixes
to B those fixes are lost when A takes a fresh release of B.
I am sure that branching can somehow be used to solve this problem but
I am not sure exactly how. Any suggestions?

I seem to recall that you're a regular here, so I might have missed
something, but the good old CVS "vendor branch" seems like the
traditional solution for this:

- keep a branch for Byzantine releases of B
- new releases from Byzantium are just overwritten onto that
branch: B0, B1, B2 ...
- when you have B1 in mainline already but need stuff from B2, do a
merge from B2 to mainline.

However, in my limited experience this only gets more and more painful
over time. You're probably working in different directions, and their
changes will be more and more at odds with yours, your merges will
create more and more bugs ... I don't know what to suggest.

/Jorgen

[Andrew]

Post by Jorgen Grahn
A wiktionary search for blat gives "to cry, as a calf or sheep" or "to
produce an overrich or overblown sound on a brass instrument". I guess
you meant "blast away", "pave over" or "overwrite"?

Er, yes ;-)

Post by Jorgen Grahn

Post by Andrew
This means that whenever A make their own independent fixes
to B those fixes are lost when A takes a fresh release of B.

I seem to recall that you're a regular here, so I might have missed
something, but the good old CVS "vendor branch" seems like the
However, in my limited experience this only gets more and more painful
over time. You're probably working in different directions, and their
changes will be more and more at odds with yours, your merges will
create more and more bugs ... I don't know what to suggest.

Hmm. It looks like I am stuck. We will just have to get B to take on
the changes but this is really really difficult. Deep sigh.

-Andrew M.

[Jorgen Grahn]

Post by Andrew

Post by Jorgen Grahn
A wiktionary search for blat gives "to cry, as a calf or sheep" or "to
produce an overrich or overblown sound on a brass instrument". I guess
you meant "blast away", "pave over" or "overwrite"?

Er, yes ;-)

Post by Jorgen Grahn

Post by Andrew
This means that whenever A make their own independent fixes
to B those fixes are lost when A takes a fresh release of B.

I seem to recall that you're a regular here, so I might have missed
something, but the good old CVS "vendor branch" seems like the
However, in my limited experience this only gets more and more painful
over time. You're probably working in different directions, and their
changes will be more and more at odds with yours, your merges will
create more and more bugs ... I don't know what to suggest.

Hmm. It looks like I am stuck.

Hey, I said *limited* experience. Maybe someone here has a great
design for these situations ...

By the way, one group of people who deal with this is the Debian
Linux developers. 'B' here is the upstream developers of the package
in question, and 'A' would be the Debian project, which for
different reasons feels a need to patch B before making it part of
Debian. These two groups don't always get along, and it's all in the
open.

Post by Andrew
We will just have to get B to take on
the changes but this is really really difficult. Deep sigh.

Some old-fashioned blackmail, maybe? If you can fit a private
investigator's bill into the project budget somehow ;-)

/Jorgen