info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: refactoring when using CVS


From: Noel Yap
Subject: Re: refactoring when using CVS
Date: Sat, 23 Feb 2002 05:15:51 -0800 (PST)

--- "Greg A. Woods" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]