Branch merges

[Ian Boston <ie...@tfd.co.uk>]

I have been attempting to merge changes from trunk into the 1.0.x  
branch, but it has wandered a bit. The result is that some fixes wont  
merge without re-work. In particular SHINDIG-785 which has  
dependencies on the google collections re-factor done mid December,  
which itself has other dependencies. About 1/4 of the commits to trunk  
since 5 December have been merged into the branch.

IMHO we have 2 options.
1. re-branch
2. only apply a very limited set of patched from trunk to the branch.

Which one ?
The patch of least resistance says 2, but that could be hard for those  
wanting to see fixes in the release.
Ian

Re: Branch merges

[chico charlesworth <ch...@googlemail.com>]

Is the 1.0.x branch up-to-date with all of the refactoring of the google
collections?
If not, then SHINDIG-785 should only be merged into the branch once that's
done.

2009/1/7 Ian Boston <ie...@tfd.co.uk>

> I have been attempting to merge changes from trunk into the 1.0.x branch,
> but it has wandered a bit. The result is that some fixes wont merge without
> re-work. In particular SHINDIG-785 which has dependencies on the google
> collections re-factor done mid December, which itself has other
> dependencies. About 1/4 of the commits to trunk since 5 December have been
> merged into the branch.
>
> IMHO we have 2 options.
> 1. re-branch
> 2. only apply a very limited set of patched from trunk to the branch.
>
> Which one ?
> The patch of least resistance says 2, but that could be hard for those
> wanting to see fixes in the release.
> Ian
>

Re: Branch merges

[Chris Chabot <ch...@google.com>]

The wonderful world of branch management, ugh it's a headache sometimes.

On the php side i've been very careful to keep the 2 tree's in sync, ideally
a fix should be always be applied to both, especially during the release
process since we haven't actually produced a release yet.

To be honest I have slightly lost the overview of what needs to happen on
the java side of things to make a release happen, there's a number of bugs
people identified as 'blockers', have those been addressed yet? And would
merging in changes from the trunk disrupt the stability of the 1.0.x tree?
(there has been quite a bit of proxied content/data pipelining work on the
trunk right?)

At some point in the near future (say next week) I would like to start
landing some disrupting changes to php, so re-branching would be undesirable
after that from my perspective.

On Wed, Jan 7, 2009 at 4:27 PM, Ian Boston <ie...@tfd.co.uk> wrote:

> I have been attempting to merge changes from trunk into the 1.0.x branch,
> but it has wandered a bit. The result is that some fixes wont merge without
> re-work. In particular SHINDIG-785 which has dependencies on the google
> collections re-factor done mid December, which itself has other
> dependencies. About 1/4 of the commits to trunk since 5 December have been
> merged into the branch.
>
> IMHO we have 2 options.
> 1. re-branch
> 2. only apply a very limited set of patched from trunk to the branch.
>
> Which one ?
> The patch of least resistance says 2, but that could be hard for those
> wanting to see fixes in the release.
> Ian
>

Re: Branch merges

[Paul Lindner <pl...@hi5.com>]

I'll pull in the google-collections mods in revisions  
724939,727033,727448 so future merges are less painful.

On Jan 7, 2009, at 10:02 AM, Kevin Brown wrote:

> Id prefer only pulling in bug fixes. The pipelinig / proxied stuff  
> is way
> too early for a release.
>
> On Jan 7, 2009 7:28 AM, "Ian Boston" <ie...@tfd.co.uk> wrote:
>
> I have been attempting to merge changes from trunk into the 1.0.x  
> branch,
> but it has wandered a bit. The result is that some fixes wont merge  
> without
> re-work. In particular SHINDIG-785 which has dependencies on the  
> google
> collections re-factor done mid December, which itself has other
> dependencies. About 1/4 of the commits to trunk since 5 December  
> have been
> merged into the branch.
>
> IMHO we have 2 options.
> 1. re-branch
> 2. only apply a very limited set of patched from trunk to the branch.
>
> Which one ?
> The patch of least resistance says 2, but that could be hard for those
> wanting to see fixes in the release.
> Ian

Paul Lindner
plindner@hi5.com

Re: Branch merges

[Kevin Brown <et...@google.com>]

Id prefer only pulling in bug fixes. The pipelinig / proxied stuff is way
too early for a release.

On Jan 7, 2009 7:28 AM, "Ian Boston" <ie...@tfd.co.uk> wrote:

I have been attempting to merge changes from trunk into the 1.0.x branch,
but it has wandered a bit. The result is that some fixes wont merge without
re-work. In particular SHINDIG-785 which has dependencies on the google
collections re-factor done mid December, which itself has other
dependencies. About 1/4 of the commits to trunk since 5 December have been
merged into the branch.

IMHO we have 2 options.
1. re-branch
2. only apply a very limited set of patched from trunk to the branch.

Which one ?
The patch of least resistance says 2, but that could be hard for those
wanting to see fixes in the release.
Ian