On 6/3/09, Magnus Hagander <mag...@hagander.net> wrote: > Robert Haas wrote: > > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
