>>>>> "RL" == Richard Lowe <[EMAIL PROTECTED]> writes:
RL> That at most a single delta contained (as comments, at least) one CR RL> and one ARC case. I think we want to allow multiple ARC cases. It's not unusual for a project, particularly a large or complex one, to have multiple ARC cases. The ksh93 project is working on at least its third ARC case. I'd also like to work through some of the implications of the "one CR per commit" approach. First, if a changegroup has multiple changesets, what are the requirements for those changesets? Do they have to individually build? Do they have to be individually revertable? If the answers are yes, we've just imposed an additional testing burden on developers that is not present today with Teamware. If the answers are no, how will the gatekeeper know what's safe to back out? He can't do it at the changeset level, he'll have to look at the log of changegroups. This is no different from the situation today, of course. But it does mean we won't get as much benefit from the changeset approach as we might like. Second, consider this scenario: bug A is that an application fails to check the return value from a malloc() call. Bug B is that the application is slow in some situation. As part of fixing bug B, I restructure the application, and the offending malloc call goes away completely. If the changeset can only have a single CR, what do I do here? It doesn't make sense to me to dummy up a changeset that just addresses bug A. I suppose I could close bug A as a dup of bug B, but that's a hack. They're not the same bug. If the fix gets backed out, it's likely that only B will get reopened. A will remain closed in the bug database, which is incorrect. mike _______________________________________________ tools-discuss mailing list [email protected]
