Refactoring and Version Control Systems
How do people generally deal with refactorings and Version Control Systems? I'm thinking about refactorings which affect the name and/or location of a source file, such as renaming a class, or moving a class to another package.
We use VSS. These sort of refactoring are a pain to carry out, as you have to manually do the renaming/moving in VSS and separately do the refactoring in IDEA, and try to avoid getting tied in knots.
How do other people deal with this? Can other VCS's deal with this better? Does IDEA integration deal with this for other VCS's?
When using VSS at least, it seems to me that changing the contents of a file is fine - you can just check it out, change it at will (editing using IDEA) and check it back in. However, if you're renaming/moving a file in IDEA, the corresponding VSS action would have to happen at the same time, meaning you're committing immediately.
So I'm not sure if this is a VSS-specific problem, or a more general problem with CVS's.
请先登录再写评论。
Calum MacLean wrote:
it's very much a problem with VSS
I am ex[perienceing it now - while when in the pastI was using CVS
things wenty much much better as IDEA offered (eg on a move) to delete
the file from the old location and to add the new one.
the changes happened only on your local copy, until when executing cvs
commit
Edo
I use CVS. when i do a rename/move refactor, i get prompted by IDEA to delete the file from CVS, then add the new (newly named) file. so i basically say, do refactor, hit enter twice to confirm cvs remove/cvs add, then its done.
So, to get it clear in my head, when you do a move/rename refactoring, IDEA will prompt you to make the CVS change when you're doing the refactoring in IDEA. i.e. the whole process of moving/renaming and changing CVS is atomic.
Or can you make multiple moves before choosing to commit to CVS (or choosing to abandon the refactorings)?
If the former, does this mean that you can't really do "experimental" refactoring - rearranging classes/packages, with a view to possibly committing it to CVS later, but possibly not?
It would also makes these refactorings a bit different from normal refactoring, where you can move stuff about within a class at will, and decide later whether to commit to CVS or not.
When doing this refactoring in CVS, if you effectively remove the file then add it somewhere else, do you lose the file's history of changes? Is the remove+add equivalent to a "move", or not?
Finally, if this can be done for CVS, is there anything in principle which would stop this being done for VSS? Or is there something about VSS which doesn't allow this to be done?
Thanks for your replies!
Calum
Calum MacLean wrote:
yes - until you cvs commit nothing happens to the repository
no - cvs commit is not really atomic
also, if you decide not to commit to restore your local copy to the
initial state you basically should delete it and checkout (in cvs
parlance == vss getlatest) it again.
expect sometimes some manual pain ... for instance you cannot later
re-add a file with the same name of one that has been removed, unless
you do some manual operations (which I don't rememeber actually).
yes, although for speed and ease I'd try the layout without involving
cvs ...
yes, you lose history attached to that file, but the removed file still
is visible when going back in the past ...
what you REALLY want is subversion http://subversion.tigris.org/
well, VSS AFAIK does not remove a file locally from all users working
copy when they synchronize. getlatest only adds/updates.
Edo