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: Fri, 22 Feb 2002 07:12:39 -0800 (PST)

--- "Greg A. Woods" <address@hidden> wrote:
> CVS is not and has never been very useful for
> initial development under
> any methodology that doesn't involve sharing of the
> code under
> development (and sharing in a non-XP manner!).

I disagree.

>  Sure
> there are pedants
> amongst the CVS users who check in every tiny change
> even when they're
> working all on their own, but they're the exception
> by far and while
> their change history might make for some very
> interesting micro-analysis
> of their work, it's really not of any use from an
> overall SCM point of
> view.  

I agree.

> SCM really only comes into full use once
> you've got past the
> point of the first actual release.  Only once you've
> got something that
> needs to be shared (either with other developers, or
> with the QA team,
> or even with actual end users) do you really have to
> be that much more
> careful to track how it's configured and how it is
> changed before you
> make a new release.  

I (and I'm sure many others) whole-heartedly disagree.
 SCM by definition is the identification of what goes
into a product and the control of changes into that
product.  You seem to think that it's just the latter.
 Now, using it's full definition, and the fact that XP
encourages early, small releases, the identification
portion comes in extremely early in the game.

> I'm not sure why this would be
> news to you though.

It's news to me 'cos you work under a different
definition of SCM than the rest of the world.  Here's
what I found when I did a google on "configuration
management definition"

http://www.lal.in2p3.fr/SI/CMT/show/tsld002.htm

> I have only studied the formal eXtreme Programming
> methodology from a
> distance, never really done it directly, at least
> not in a formal way
> with all of the rules it's proponents have found to
> be critical to its
> success, but from what I've learned it would seem
> the modules developed
> by a pair of programmers is never shared with any
> other pairs of
> programmers until it's effectively (if not actually)
> complete.  Maybe
> I'm micro-analyzing XP too much, but in the informal
> XP-like teams I've
> worked on in the past what I say has been absolutely
> true and I don't
> see how any of the other formal XP rules could
> change that.

It's true that each team only checks in when they have
something working.  But the definition of "something
working" can vary.

> > I really don't understand your post.  XP promotes
> > rapid, quick iterations.  Each iteration includes
> > design.  Design includes refactoring.  Therefore,
> you
> > cannot have XP without refactoring when necessary.
> 
> Yeah, but once you've reached the point of producing
> a first release
> then you don't immediately start making
> micro-releases.  Sure you can
> use XP in maintenance, but again you don't release a
> given pair's output
> to the rest of the teams until it's at least
> semi-complete.

Yes, I agree.  Let's back-track here for a moment. 
The original discussion, AFAIK, was comparing
ClearCase and CVS.  I made a statement saying that CVS
is not _ideal_ (it is usable, though) when
refactoring.  If you look at ClearCase, it handles
refactoring with ease even under a concurrent
development environment.  Of course, you're also
correct that refactoring requires fore-thought, it is
a part of design after all.  However, with CVS, you're
more apt to be forced to serialize development while
refactoring while other tools handle it more
gracefully.

> > I don't think anyone is suggesting willy-nilly
> > refactoring.  But the fact remains that XP
> includes
> > constant refactoring.  This refactoring typically
> > includes renaming and moving of files.  CVS
> doesn't
> > support such a feature.  Therefore, CVS is not
> ideal
> > for XP.
> 
> I think you're missing the point of how XP and CM
> fit together in the
> bigger picture.  It matters not what CM tools you
> use, you don't go
> trying to share all your micro-adjustments
> continuously!

I don't consider a refactoring a micro-adjustment
since it is a step in the design phase.

> Perhaps you should follow the change logs of some of
> the larger
> distributed freeware projects using CVS for CM to
> see how it works
> best.

I really doubt they've been doing XP.  The first and
only product that I've seen supporting remote paired
programming runs under JXTA.

>   In most such projects, For example in NetBSD
> and FreeBSD,
> nothing that doesn't yet work (and in NetBSD that
> often means on many,
> if not all of the supported architctures!) should
> ever be checked in.

I agree.

> How these "changes" are initially developed is
> irrelevant from the CM
> point of view of the overall project.  Some
> developers working on their
> own check in smaller working units as they create
> them, but usually the
> design of their final result was defined before they
> even began to
> work.  Perhaps some of the other changes are
> developed with XP -- you
> just can't tell without asking the developers -- and
> you don't really
> care so long as they compile and work when they're
> first checked in.

Since we're talking about refactoring, we're talking
about the design phase here, not the implementation
phase so the above is irrelevant.  And remember, this
is not a waterfall model; under XP design (and
therefore refactoring) occur often.

> Sure things don't always work perfectly when they're
> first committed,
> but that's where the shared development methodology
> supported by CVS
> starts to come into use -- other developers are now
> effectively forced
> to start using the new changes and they can commit
> their own fixes if
> there is something wrong with them.

I agree.

> In other words whether you use XP or not is
> irrelevant.  It just doesn't
> enter into the picture from the level where CVS is
> involved.

It does if you consider refactoring as part of the
methodology and whether CVS handles it well.  Of
course, you can always say, "That's you're problem,
not CVS's," but that's difficult to support when other
tools don't get in the way of your methodology the way
CVS does.

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]