Theo Schlossnagle <[EMAIL PROTECTED]> writes: > Additionally, what problem is accepting incremental patches supposed > to solve?
Keeping the individual patches reviewable is one useful goal. We may be talking at cross-purposes here. The sort of thing I think Alvaro is imagining is something like what I did a year or two back when I wanted to make the executor treat plan trees as read-only --- if memory serves, I did that in three or four commits spread over a week or two. I could have done it in one massive patch but it would have been unreadable to me or anyone else. And for that matter, the reason for doing it at all was as part of a much larger concept that's still unfinished (better caching and invalidation of plans). When you're talking about tasks of that magnitude, stepwise improvement is the only way you are going to get there at all. I really don't have any faith in the concept of doing very large tasks on a development branch and expecting to land them in one huge merge. For a nearby counterexample look at Postgres-R, which never has and probably never will manage to produce a patch that could apply to the core project's CVS head. At least not without thinking of some incremental way to do it, because by the time they bring all their changes up to HEAD, the tree has always drifted under them. There is no magic version control system that will fix that. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match