[Top][All Lists]

[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 08:54:17 -0800 (PST)

--- Mark <address@hidden> wrote:
> - if someone is working on file A on branch 1 and
> someone else refactors file A
> on branch 2, what good is a merge, using CC or CVS?
> Wouldn't the person doing
> the merge have to collect/identify the changes on
> branch 1 and then figure out
> where they go on the new refactored file on branch
> 2? (I know, functionally you
> can make the tool merge the file, but wouldn't that
> person have to stop and
> learn how things are in the refactored world to then
> be able to intelligently
> integrate needed changes in properly? How close to
> (or more difficult) is this
> to/than dual maintenance?)

Since CC versions the contents of elements rather than
versioning the contents of filenames, it's better able
to track of changes to the contents versus changes to
the filename.  For example, under CC, if someone
renames a file along a branch while someone else is
modifying the file, the merge occurs seemlessly.  IOW,
in the CC world, the file would be referred to by two
different filenames (similar to hardlinks).  However,
under CVS with the same situation, there are now two
files and the developer who modified the file will
need to do something manual (ie outside the realm of
the tool) to merge the modifications.

> - if the above merging example issue isn't really an
> issue in refactoring, and
> refactoring is limited to renaming of existing files
> only (not adding/removing
> files), and you refactor alot for some reason, then
> CC may be required to keep
> up with the way development is done. (but wouldn't
> CC be overkill in an XP
> environment of 2-12 developers, and wouldn't
> refactoring in large efforts be
> counter productive with all the constant
> re-learning?)

If the refactoring occurs constantly, then they can't
be that large so developers can keep up with them as
they happen.  OTOH, if the developer stays out of a
region of code for a while (IMHO, teams should try to
avoid this no matter what methodology is being used),
then, yes, there'd be a big learning curve.  I think,
though, that there'd always be a big learning curve if
the developer tended to stay out of certain regions,

> Can you refactor without
> renaming files? 

Yes.  It would depend on what kind of refactoring you
were doing and what language you're using.  For
example, in Java (or at least the way I've used Java),
there's a very strong mapping between package names
and directory names.  If one wanted to reorganize the
package hierarchy, one would need to reorganize the
directory hierarchy causing renames of directories
(or, in the CVS world, moving of files).

> How does refactoring come up with
> better names for files (which
> need to be the class names in java)?

I'm not sure if I understand your question so I'll do
my best in answering.  Renaming classes is also a type
of refactoring and, yes, renaming classes in Java
forces a file rename.  In the context of concurrent
development with unreserved checkouts, you run into
the same problems as was alluded to in your first
question -- it may help to look at unreserved
checkouts as virtual or anonymous branches.

> - if refactoring creates/removes files, then how can
> CC or CVS help. If file A
> above is refactored off of branch 1, then how can a
> merge of changes from file
> A on branch 1 to branch 2 be done? How would CC or
> CVS know where to merge the
> changes to the class(es) in file A, if the classes
> are no longer in file A on
> branch 2? Does refactoring create/remove files?

In CC, directories are also versioned, so a file
rename is just a modification to the directory, and a
file move is just modifications to two directories
(the source and the destination).  One never loses
track of the file since there's always only one
versioned element (the one renamed or moved).

In CVS, directories are not versioned, so one would
have to mimic file renames and moves and file removes
and adds thereby losing track of what happened to the
file (since there are now two versioned elements, one
removed and one added).

> Thanks for any clarifications to my
> misunderstandings. :)

Let me know if you need any further clarifications. 
Many (if not all) of your questions were very similar
so please forgive any answers that were redundant.


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games

reply via email to

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