Re: refactoring when using CVS

[Paul Sander]

I won't comment on the mechanics of refactoring specifically, but I'll
try to answer your questions with regard to SCM artifacts.  Refactoring
is another way of describing changes to the design of a project, which
is still largely an art form and it's an exercise for the developer to
determine when and how it's done appropriately.

>--- Forwarded mail from address@hidden

>--- Kaz Kylheku <address@hidden> wrote:
>> In article <address@hidden>, Tom Plunket wrote:
>> >I haven't found myself renaming files much, quite honestly.  How
>> >does CVS deal with file deletions and additions?  That's the way
>> >I'd prefer to go over renaming anyway.
>> 
>> Deleting and adding creates a new object, which has no relationship
>> to the old. Suppose someone is working on the old one in parallel and
>> now wants to merge. But oops, you have removed it.  In a version control
>> system that supports true renaming, this isn't a problem. The merge
>> will happily go to the file under its new name.

>I really haven't read/found  much about the details/mechanics of refactoring,
>but maybe a response to these statements might make things clearer to me about
>what the results of refactoring are on the version control tool activities:

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

If you created the branches to support concurrent development (i.e. with
the intent to merge later), then dual maintenance would seem to be not an
option.

If the result of the refactoring doesn't result in the creation of new
files (which is to say, refactoring rearranges the contents of an existing
file), then any merge tool can be used effectively to produce meaningful
results (though the result of the merge would still need editing in the
general case to make it useable).

Some merge tools are better than others.  The one supplied with ClearCase,
for example, recognizes when lines of text actually move, rather than show
such migrations as insertions and deletions.

>- 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?) Can you refactor without
>renaming files? How does refactoring come up with better names for files (which
>need to be the class names in java)?

In the event that files are renamed on one branch then merged to the other,
ClearCase merges the filename changes as well, and the result of the merge
is a source tree that has the same shape and names as the contributor to the
merge.  In CVS, the rename is best handled as a remove/add pair, and after
the merge the developer is left with two files having the same content and
must decide which is the proper one to keep.

Certain types of conflicts, such as modifying a file on one branch and
renaming it on the other, are handled well by ClearCase but not by CVS.
This is because ClearCase tracks the content of the file indepently of
its identity in the filesystem, whereas CVS creates two different
containers that each contain a subset of the file's history.

>- 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 the event that refactoring removes some of the content from one file
and stores it in a newly created file, or if it merges the content of a
file into another file and deletes the empty one, then life becomes more
interesting.

In the event that a new file is created, then there are several cases to
consider:  The refactoring is the only change, the refactoring is done in
parallel with another change, and refactoring is done on both branches.

The first case is not a problem for either ClearCase or CVS; they can
merge the creation of new files easily and as well as perform the content
merge on the modified file.  Recording the fact that a file was split in
two is a different exercise; ClearCase provides mechanisms that can be
used for this purpose, but they're primitive and require triggers and
wrappers to do well.  CVS provides no such capability, so the developer
must describe his actions in commit comments.

The second case is like the first case, with the addition of a content
merge.  If the change was made in the section of code that was removed
to the new file, then the conflict must be resolved manually with the
editor.  If it's in the code that remains in the original file, then
the merge tool can do something useful with it.

The third case has two sub-cases:  The new file has the same name on
both branches, or it doesn't.  CVS treats the two cases differently,
but ClearCase treats them the same.

If the new file has the same name on both branches, then ClearCase
creates an evil twin condition in which two history containers are
created for the same file.  This isn't a problem in CVS because the
mapping of files to history containers is constant.  To resolve the
situation in ClearCase, the developer must choose to keep one or the
other of the two created files, and migrate the needed parts from the
discarded file to the new one.  In CVS, a content merge is all that
is needed.  (ClearCase also provides a mechanism that can be used to
detect an evil twin condition, and there's software available to
enforce policies prohibiting them.)

If the new file has different names on both branches, then something
like the evil twin condition exists in both CVS and ClearCase, and
the recovery is the same.

In the event that refactoring causes a file to be removed, then there
are three cases:  The contents of the file are moved to another file,
the contents of the file are moved to different files on each branch,
the contents of the file are modified on one branch and moved to another
file on the other branch.

The first case is straightforward, and both CVS and ClearCase handle
them well.

The second case is also straightforward, but this type of conflict
requires manual resolution.

In the third case, the migrated code appears in a content merge in the
new file, and the modify/remove conflict is detected by the tool for
manual resolution.

>--- End of forwarded message from address@hidden