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 [EMAIL PROTECTED] >--- Kaz Kylheku <[EMAIL PROTECTED]> wrote: >> In article <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
