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.

4 comments
Comment actions Permalink

Calum MacLean wrote:

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.


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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

Calum MacLean wrote:

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


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


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?


yes, although for speed and ease I'd try the layout without involving
cvs ...


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?


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/


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?


well, VSS AFAIK does not remove a file locally from all users working
copy when they synchronize. getlatest only adds/updates.


Thanks for your replies!

Calum

Edo

0

Please sign in to leave a comment.