Re: refactoring when using CVS

[Greg A. Woods]

[ On Thursday, February 21, 2002 at 17:26:12 (-0800), Tom Plunket wrote: ]
> Subject: Re: refactoring when using CVS
>
> What, pray tell, does "sharing in an XP manner" mean if not
> "anyone can edit anything at any time"?

"Only one pair integrates code at a time"

> Greg A. Woods wrote:
> > 
> > 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?

It's not necessarily a bad way to work -- it's just not necessary to
work that way and still produce a change audit trail that's sufficient
for the purposes of the project as a whole.

Where it becomes bad is when it adversely impacts other members of a
multi-person project.  CVS provides ways to isolate such practices
though so that they don't adversely impact the project (per developer
branches).

> I find that checking in micro-changes is a good thing.  Code
> compiles, tests pass, check it in!

sorry, by "every tiny change" I meant even the ones that might not
compile, and might not test successfully, and even those that might be
incomplete in the sense that they cannot yet be successfully integrated
in any way with the whole product.  Believe it or not but some people
actually think doing such a thing is a good idea.  Provided they don't
get in the way of other developers, I can't argue against them either!  ;-)

That kind of practice is strictly forbidden on any public branch in the
likes of the *BSD projects, since it would most definitely adversely
impact other developers (those projects work 24x7 around the world).

> That makes backing out bad
> changes as easy as a checkout.

No, not always that easy -- but maybe as easy as a merge.

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

well, "Xcuse me!"  -- obviously we're saying the same things with
different words.

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

How do you know?  An operating system is an awfully big project.  Many
parts of it can be worked on independently by small teams, and if those
teams are broken up into pairs who do XP within the micro-project and
then their "final" result is committed to the main repository then how
is it that they are not doing XP?  :-)

What this proves is that XP need not have any direct interaction with
the shared CVS repository used by a larger encompassing project.

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

"Micro-releases" implies many different releases going out to the end
users on a frequent basis.

If you're doing real "Release Management(TM)" (whatever that means! ;-),
complete with full unit testing, accpetance testing, QA tracking, and
then post-release bug tracking and fixing, then there's only a small
number of releases that can possibly ever be managed effectively by any
sized team, not to mention that only a small number of releases can
actually fit through such a process in a fixed amount of time.  The
bigger the product the fewer releases you can effectively manage.

If you try to do micro-releases then you will inevitably end up with a
complete and total mess that no version tracking system will ever dig
you out from underneath, no matter how many monkeys you put on the job.
(because your customers will have gone elsewhere for a working 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.

I'm hoping your misplaced sarcasm comes from the fact that you don't
seem to have a clue about the current state of ongoing development of
the *BSD projects......

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>