I'm using the VSIP client. In the MSSCCI client when a file is checked in, then you right-click in VS.NET's solution explorer and choose RENAME, it will rename the file and underlying designer/resx and the file remains checked in. However, in the VSIP client, I make sure the file is checked in before I do anything, I then right-click and RENAME, it does the renaming but the file is then checked out. It seems like the behavior is different between MSSCCI and VSIP. I prefer the file remains checked in after the rename as I have to take another step to then check it in, which I'm not sure is or should be necessary.
FYI (4.0.5)
Renaming leaves checked out
Moderator: SourceGear
Renaming leaves checked out
Neal Culiner
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
NC Software, Inc.
http://www.nc-software.com
Vault 5.1.2
VS 2010/C#
Windows 7 Ultimate x64
VB.NET Forums: http://www.vbdotnetforums.com
Renames and deletes should require check in
One of the huge problems with Microsoft's approach (MSSCCI) to source control is that most things accumulate in Pending Checkins and are sent to the server all at once when you do a check in (this is the good part), but renames and deletes happen immediately (this is the awful part).
Therefore, if you have a continuous integration system such as Cruise Control, your build breaks immediately if you ever rename or delete anything, because the other changes you made (such as updating references to the renamed thing) have not been checked in yet.
It's very important to have consistent behavior when it comes to either accumulating changes or doing them immediately.
I haven't used the new (VSIP) client yet, so I don't know exactly how it works, but what I've said above is important and true regardless of current behavior. I think you want to reconsider flagging this as a bug.
Therefore, if you have a continuous integration system such as Cruise Control, your build breaks immediately if you ever rename or delete anything, because the other changes you made (such as updating references to the renamed thing) have not been checked in yet.
It's very important to have consistent behavior when it comes to either accumulating changes or doing them immediately.
I haven't used the new (VSIP) client yet, so I don't know exactly how it works, but what I've said above is important and true regardless of current behavior. I think you want to reconsider flagging this as a bug.
I spent some time looking at this issue this morning. It looks to me like rename behaves correctly with respect to checkouts. That is:
1. If renaming a file causes the file to be modified (e.g. Class1.cs->Class2.cs, where Class1 is defined in the file, so its text is automatically changed to Class2) a checkout is performed.
2. If renaming a file does not cause the file to be modified, the file is not checked out.
1. If renaming a file causes the file to be modified (e.g. Class1.cs->Class2.cs, where Class1 is defined in the file, so its text is automatically changed to Class2) a checkout is performed.
2. If renaming a file does not cause the file to be modified, the file is not checked out.
Ian Olsen
SourceGear
SourceGear