Re: refactoring when using CVS

[Noel Yap]

--- "Greg A. Woods" <address@hidden> wrote:
> [ On Friday, February 22, 2002 at 08:28:16 (-0800),
> Noel Yap wrote: ]
> > Subject: Re: refactoring when using CVS
> >
> > Since bare-bones CVS pretty much forces you to tag
> (ie
> > branch) all files in the module, either it's a
> slug
> > when it comes to large code bases, or you're
> forced to
> > create a wrapper to manage branches for only parts
> of
> > the module.
> 
> Would you consider a *BSD kernel to be a "large code
> base"?
> 
> I was going to tell you how many total lines of code
> there are, but it
> fails the simple one-liner on both NetBSD and even
> FreeBSD with far
> fewer architectures:
> 
>       $ wc -l $(find . \( -name CVS -prune \) -o -type f
> -print)     
>       ksh: wc: Argument list too long

If you'd read anything I posted, you'd know that the
number of lines of code is irrelevant.  What is
relevant is the number of files.

> The NetBSD folks don't go wild with private
> developer branches, but
> they are in regular use.

I think they may be in regular use, but it's just a
case of putting up with CVS's sluggishness.

> > Personally, I would opt for task branches over
> > developer branches since then, there'd be a very
> good
> > mapping between the branch and a change set and
> > multiple developers could work on the same branch.
> 
> Hmmm.... yes, well in NetBSD the "private" branches
> really are "task
> oriented", but one developer is normally in charge
> of each.

Then please call them by their proper names, "task
branches".  It's irrelevant whether only one developer
is performing the task or not.

OK, since they are task branches, then it's valid to
assume that a new task branch would be created for
each task.  Each file within the project would need to
be branched regardless whether they're going to be
modified or not.  This is a long task in large
projects (much longer than if one would branch only
the files that'll be modified).

> > Still, there's the problem of possible multiple
> > refactorings having to be merged.
> 
> Huh?  Do you mena "possible multiple file renames"?
> 
> Refactoring (at any level) does not _require_
> renaming files!!!!

It requires being able to rename files when you're
programming in Java.

It requires being able to rename files when you need
abide by organisation standards.

> > And how likely do you think a geographically
> disperse
> > team is doing paired programming.
> 
> That's a meaningless (implied) question.

Why is it?  Open source projects are usually
geographically disperse.  XP requires paired
programming.  Therefore, open source XP projects would
require geographically dispersed paired programming.

> >  My guess is if the
> > team is large enough, there's bound to be a pair
> out
> > there doing this, but as a whole, I wouldn't say
> the
> > entire team is doing it.
> 
> Indeed, but who cares?  You don't know how any given
> person with commit
> access has managed to write the code being
> committed.  XP effectively
> requires only one person to be at the keyboard so
> the answer is
> unknowable.

You're missing the point.  XP requires paired
programming.  Such distributed paired programming can
only exist with group collaborative editors that are
just coming into existence and so aren't widely used.

> Now except for the "Fix XP when it breaks" rule
> there's the other rule
> about changing the pairing frequently....  ;-)

This is even more of a reason why it's extremely
unlikely open source development uses XP.

> >  And if the entire team isn't
> > doing it, and they're using CVS, then it's
> irrelevant
> > to this discussion.
> 
> Why?  What difference does it make how many members
> of the team do XP?

Because of the topic of this thread.  XP requires
constant refactoring (which often-times includes file
moves).  When using CVS, one would have to serialize
development under such circumstances.

> If even one pair do so then CVS is involved --
> more-so even than if all
> members of the team are doing XP!

Then how do they handle the constant refactoring? 
Once again, my stance here is that CVS is not _ideal_
for it.  From some of your past posts, I thought you
agree.  What are you arguing about?

> Refactoring at the design level does not require
> file renaming!!!!

Refactoring will eventually require file renaming (eg
when the file was just misnamed to begin with).

> (and in any case it's irrelevant -- its no easier or
> harder than if
> someone does an implemntation level refactoring that
> results in some
> file renames without doing XP)

I agree.  But since refactoring is such an integral
part of XP, refactoring involves moves, and CVS
doesn't ideally handle moves, then CVS isn't ideal
when refactoring or when using XP.

> > I think you seem to think most real-world projects
> > reflect the same needs as that of *BSD.
> 
> They are very good examples of large and diverse
> projects that are using
> CVS very successfully in a very public (and thus
> measurable) way.

And you think there's no room for improvement?

Also, the people working on such projects aren't as
diverse as ones working on real-world projects. 
Therefore, *BSD doesn't reflect real-world projects.

> >  This leads me
> > to the question, when was the last time you've
> worked
> > in a corporate environment and how long did it
> last? 
> > I don't mean this question to be insulting, it's
> just
> > that you have a completely different mind-set from
> > many other people on this list and I would like to
> > understand it better.
> 
> My answer is irrelevant.

Sure it is.  It gives a hint as to why you think and
communicate the way you do and why it's such in
conflict with how many others on this list think.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com