--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote: > [ On Friday, February 22, 2002 at 08:09:28 (-0800), > Noel Yap wrote: ] > > I would argue that "All code must have unit tests" > is > > as practically unenforcible as "All commits must > have > > comments" since enforcing such rules using tools > would > > just get garbage tests and comments. > > You're obviously forgetting that peer pressure and > management rules, in > combination with the necessary reviews forced by a > two-phase commit, > ensure that no code gets commited without valid and > useful unit tests.
You're right, but CVS can be used in this way, too. Oh, except that there's no ACL's on branches. But what does this all have to do with refactoring under CVS? > > I would also > > argue that enforcing "All code must pass all unit > > tests before it can be released" is the job of the > > version control tool (although it is part of the > > overall SCM picture), but propertly supporting > > moves/renames under refactoring is. > > Exactly -- which is why Aegis is better at it > because it fails any > commit if there are problems with any unit test, and > it runs every unit > test for every commit (or at least it can be > configured to do so). Sorry, I had meant: "All code must pass all unit tests before it can be released" is NOT the job of the version control. Besides, aren't we then agreeing that CVS is not ideal under refactoring (assuming moves/renames are part of refactoring in general)? > > Nope. As (I think) Kaz had posted previously, CVS > > doesn't handle well (if at all) concurrent > development > > while move/renames are occurring. > > I think you've missed a point, again. XP implies > there is little, or > no, concurrent development -- concurrency happens > only within a pair and > since pairs only commit one at a time there's no > time for conflict, > especially not because of renames in change sets. What??? Since when does "serial commits" mean "serial development"? Can you please work with other people within an XP project before making such comments? Again, your thinking is completely contrary to others', can you please explain this? Are we to believe that the rest of the world is wrong while you are right? OTOH, if your statement is true (which I don't believe it is), then you wouldn't be using CVS the way CVS was intended (ie with concurrent development). This means that CVS still isn't ideal for XP (a serial development tool would be). > No, it doesn't really -- it just means that the > choice of version > tracking tool is irrelevant to this methodology. You keep ignoring the fact that, once again: 1. Moves/renames often-time occur during refactoring. 2. CVS doesn't handle moves/renames well (especially under concurrent development). 3. Refactoring is an inextricable part of XP. 4. XP is a methodology. Taking the above statements, please explain either which of them are false, or why CVS would still be ideal for XP. More generally, just taking the first two statements, explain either which of them are false, or why CVS would still be good while refactoring? Noel __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs