On 6/3/09, Magnus Hagander <magnus@hagander.net> wrote:
> Robert Haas wrote:
> > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
> >>> I'm not sure whether we should mark the old branches getting merges
> >>> down or the new branches getting merged up. I suspect I'm missing
> >>> something but I don't see any reason one is better than the other.
> >> If you go from older to newer, the automatic merge algorithms have a
> >> better chance of doing something smart since they can track previous
> >> changes. At least I think that's how it works.
> >>
> >> But I think for most of the changes it wouldn't make a huge difference,
> >> though - manual merging would be needed anyway.
> >
> > In practice, isn't it more likely that you would develop the change on
> > the newest branch and then try to back-port it? However you do the
> > import, you're going to want to do subsequent things the same way.
>
>
> That's definitely the order in which *I* work, and I think that's how
> most others do it as well.
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local per-fix branches),
it is possible to separate the fix-developement from final representation.
--
marko