WeirdAl what's this nsINode thingy? ah, hell, you bitrotted me AGAIN didn't you? :) bz mmm... maybe depends I did wait till after you landed your doRemoveChild stuff, right? WeirdAl yeah, you did, but I just reposted the mutation-events-for-standalone-docs patch a couple days after that patch landed WeirdAl chuckles, annoyed WeirdAl that's got to be the fifth time I've been bitrotted, at least bz WeirdAl: does this really break that? WeirdAl: with a very few exceptions this should be very very compatible with all existing code WeirdAl bz: it probably broke the patch (the newest version of the muts patch, that is) I'll know when this fresh tree checkout finishes bz WeirdAl: URI? WeirdAl: to patch? WeirdAl https://bugzilla.mozilla.org/attachment.cgi?id=208460 I'm not really upset -- patches that don't have r+sr, nobody owes anything to probably affects smaug's "centralize event dispatch" patch as well (which didn't compile) bz ah yeah @@ -2759,23 +2766,25 @@ doInsertChildAt(nsIContent* aKid, PRUint That hunk will have conflicts WeirdAl probably a few others too damn, why you content guys gotta be so proactive? :-D how's a little wannabe going to keep up? bz mmmm good question. ;)
In actuality, it's the third time a patch on bug 201236 has been bitrotted. But there have been a couple times where, while I was waiting on the doRemoveChild patch (for bug 312522), that the underlying code changed.
I guess the heart of my gripe (which isn't too serious, just mildly annoying) is that patches can land without much consideration for other work happening in the same space and waiting for reviews. Just a little consideration for your fellow contributors would be nice.
Posted by WeirdAl at January 18, 2006 8:10 PMAren't situations like these the entire point in CVS? If so, isn't it doing a pretty bad job?
(From Alex: No, it's not CVS's fault if we hit a conflict.)
Posted by: Ben Basson at January 19, 2006 12:31 AMPerhaps its time to introduce a checkout monitoring system for individual functions. The checkout could be used to help manage who is changing what. If necessary, it could allow multiple people to check out the same thing, but at least warn them (and the others who checked it out) that multiple copies of the same module are checked out. This would give you a chance to take a look at the other bugs to see if it is really worth making your code change.
When you check out a bit of code, it would automatically notify you if anyone else is editing that code (or any interfaces for code that are called that code). Also, while you have the code checked out, you would be e-mailed if anyone checked in/out code related to your code. When you finally check in the code, it would automatically take you off the list.
You could check out the interface to function xxx (meaning you are going to change the arguments/return value of the function). Alternatively, you could just check out the implementation of the function (or even just a snip of code), but the overall interface and functionality of the function would not change.
Of course, this creates another obstacle to fixing code. However, as the Mozilla codebase gets more complex, and more people simultaneously make code changes, it is a necessary evil.
(From Alex: I think conflicts like the one I had are relatively rare. Believe me, my rant is meant to be taken with a large grain of salt.)
Posted by: Racer at January 19, 2006 7:04 AMFwiw, as far as rare goes... I get to merge 2-3 things a day, usually. ;) So they're not _that_ rare.
But yes, this is the point of CVS, and CVS is working right in this case.
Posted by: Boris at January 20, 2006 8:56 AM