Re: refactoring when using CVS

[Tom Plunket]

Greg A. Woods 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!).

What, pray tell, does "sharing in an XP manner" mean if not
"anyone can edit anything at any time"?

> 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...

Is the assertion that this is a bad way to work somehow?

I find that checking in micro-changes is a good thing.  Code
compiles, tests pass, check it in!  That makes backing out bad
changes as easy as a checkout.

> 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'm not sure why this would be news to you though.

It's shared as soon as it's checked in, and if it's checked in as
soon as it works, what's the problem?

> I have only studied the formal eXtreme Programming methodology 
> from a distance...

Sounds like it's been studied only third- or fourth-hand, at
that.

> ...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.

As a frequent poster here once said to someone else- "Bzzt, wrong
answer.  Thanks for playing, come again soon."

"Complete" and "satisfies current requirements" are considerably
different ideas, and pretty much the fundamental reason why the
above statement is completely wrong.  Software is never complete,
and during development the XPer knows that the software isn't
effectively complete or nearly complete or even somewhat
complete.  Software is.

> 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.

If they aren't checking in several times a day, they aren't doing
XP.  Period.

> Yeah, but once you've reached the point of producing a first 
> release then you don't immediately start making micro-releases.

Why not?  (Yes, again, I write actual software being used by
actual people on a well-funded team by one of the largest
companies on the planet.)

> 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!

Share your micro-adjustments or you aren't doing XP, regardless
of your CM solution.

> 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.   In most such projects, For example in NetBSD and FreeBSD...

"This is the way it's always been done in the past, so it's the
only way."  Thanks for the advice, dad.

Rather, perhaps I'll keep using CVS the way I want to, because it
works.  Makes more sense to me than listening to someone who
clearly makes completely unfounded statements anyway.

> 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.

Whoa- a statement about XP that isn't wholly and incredibly
wrong?!?  Amazing.

-tom!