| T O P I C R E V I E W |
| jfreeman |
Posted - Oct 31 2006 : 6:59:10 PM
When refactoring where some source files are readonly (i.e., I haven't checked them out yet), it beeps wildly (can I turn this off?) as it tries to make each change to each readonly file. It ends up changing the files that aren't readonly, which leaves the project in a partially refactored state. No error message is shown saying the refactor failed.
Why doesn't VA just check before refactoring starts and notify you that it can't start until you chnage the list of files to read/write? |
| 8 L A T E S T R E P L I E S (Newest First) |
| jfreeman |
Posted - Nov 02 2006 : 7:28:57 PM
Right, and setting the IDE option to checkout a file on edit will do just that if the source control system does a "get" on checkout, as some of them do. |
| sean |
Posted - Nov 02 2006 : 5:11:12 PM
quote:
Originally posted by jfreeman
The problem is only when using the first type of system because the refactor modifies the file in memory before checking it out.
Say someone else has modified and checked in rev 2 of the file since the last time you did a "get" of rev 1 of the file. Now you refactor starting with rev 1 of a file (that's not checked out) in memory, then checkout the file out only when you are going to save (gets the latest revision 2 to your local disk). At this point you save the file from the IDE, wiping out the rev 2 changes. On checkin, there won't be a warning from the source control system because it can't determine that you wiped out the changes -- as a far as it knows you intentionally edited out the new revision's changes.
This raises some questions - a bit of a grey area. VA makes certain refactorings available based upon the code that is available to it. If you change the code (by doing an update) in the middle of a refactoring operation, ugly things could happen. An operation that might have been available prior to the update might no longer be valid.
|
| jfreeman |
Posted - Nov 02 2006 : 4:57:47 PM
At least in Vault, it hasn't been too restrictive for us since we have it configured so checkouts don't hold an exclusive lock on the file.
In Vault, as soon as someone else checks in the file, Vault notifies me I need to merge his changes (rev 3) into my local copy sometime before I checkin my changes. Merging is done via a Vault's graphical automatic merge tool that does a 3-way diff (rev I checked out - rev 2, local file, latest rev in repository - rev 3). |
| feline |
Posted - Nov 02 2006 : 3:26:48 PM
Never having used a system that works like that, it sounds quite restrictive, but it does indicate a situation where we have a problem with refactoring.
Out of interest what happens if you check out and edit Rel 2, but when you come to check in someone else has updated the file to make it Rel 3? Due to exactly this sort of thing with CVS I am in the habit of always manually diffing a file before checking it in, to see what is going on, and to make sure I have removed any debug I inserted while working. |
| jfreeman |
Posted - Nov 02 2006 : 2:18:27 PM
I didn't realize one undo undid all the refactor changes across files -- thanks.
---
Some source control systems (Clearcase, etc.) require you to actively check out code before working on it. Others (CVS) let you change anything you like, and then merge the changes when you're ready to commit them.
The problem is only when using the first type of system because the refactor modifies the file in memory before checking it out.
Say someone else has modified and checked in rev 2 of the file since the last time you did a "get" of rev 1 of the file. Now you refactor starting with rev 1 of a file (that's not checked out) in memory, then checkout the file out only when you are going to save (gets the latest revision 2 to your local disk). At this point you save the file from the IDE, wiping out the rev 2 changes. On checkin, there won't be a warning from the source control system because it can't determine that you wiped out the changes -- as a far as it knows you intentionally edited out the new revision's changes. |
| feline |
Posted - Nov 02 2006 : 07:31:31 AM
When you trigger a refactoring operation the files are not saved, they are only modified inside the IDE, "in memory". Plus you can trigger undo after doing the refactoring. In VS2003 and VS2005 this will undo the change in all files in a single step.
I have used CVS a lot and am now using Perforce for source control, and both systems will warn you about conflicts when you come to check in the file.
Unless you are doing something clever in the source control system then you always have the risk of two developers modifying the same file at the same time. I always thought this is one of the reasons for using a source control system, to reconcile these changes as they are checked back in. |
| jfreeman |
Posted - Nov 01 2006 : 8:48:46 PM
Sorry about that, I forgot to say VS2005, VA build 1540.
I've never been able to get the SourceGear Vault + VS2005 integration to work.
With the auto-checkout workaround, isn't there risk another developer may have checked-out/checked-in the file, then the refactor would use an outdated (the last time I did a "get") file parse info to create the new refactored file image, which would wipe out the other developer's changes?
I really hope you can fix this to not start the refactor unless all the needed files are R/W (or alternatively do an undo when you hit a R/O file after file mods begin).
Jim |
| feline |
Posted - Oct 31 2006 : 7:13:25 PM
Which IDE and version of VA are you using?
The recommended workaround for now is to set the IDE to checkout the files on edit, assuming you have source control integration with the IDE. Alternatively you can set VS2003 / VS2005 to allow read only files to be edited:
IDE tools menu -> Options -> Environment -> Documents -> Allow editing of read-only files; warn when attempt to save
Looking at this is on our list of things to do
case=2153 |
