On Mar 24, 2004, at 20:29, Tom Lane wrote:
Not here. You want me to trust some bit of code (with absolutely zero understanding of the source text it's hacking on) to figure out how to resolve conflicting patches? That sounds like a recipe for big-time unhappiness.
The idea is that it's the responsibility of the branch owner to keep it up-to-date. For example, I've got a branch of tla (an arch implementation) I made soon after I started using it in order to add a command I wanted and refactor a bit of the insides. Over time, a lot of stuff has changed, but I still want my stuff to work, so as I update my branch against head of line, I make minor changes to it as things go.
The difference is that instead of having a patch sitting in a queue somewhere suffering from bit-rot, you've got a pointer to a branch that you can merge when you get around to it. You can still view it as a diff if you want, but the diff you get six months after the original submission may be quite a bit different from what you would've got at the beginning if a lot of the code around it has changed.
The difference here is that instead of submitting a patch for review, which is then frozen, the branch owner can (and that means some will, no matter what your intentions are) keep modifying the branch during the review process, other than just keeping it in sync with conflicting changes to the trunk. How do you plan to prevent that?
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
