BUG?: Source control explorer/checkin asks to save/checkout inappropriate file

I have a solution loaded that I may have (or may not have made changes to the solution file) - (It didn't ask me to checkout before now... so I don't think I did).

I went to source control explorer and checked out a word doc that was not in the solution. I edited it and went to checkin, both from the SCE and the pending checkins window it asks me if I want to save the solution file and gives me Yes, No, Cancel.

If I say Yes, it asks me to checkout (which I don't want/need to do and should not be required since the file is unrelated.) If I answer No it doesn't save and doesn't checkin. If I answer cancel it doesn't do anything either.

This seems like a significant issue as due to the integration in the IDE I can't work on independent files without it relating them to my solution somehow.

>> This seems like a significant issue as due to the integration in the IDE I can't work on independent files without it relating them to my solution somehow.

Open up another IDE that does not have an active solution.

On our boxes it typically takes 45 seconds to 1 minute to load another IDE and eats 100meg or more of memory. Usually our boxes are runing high on memory usage as we have other IDE's already open with other solutions loaded, so having one more take that much memory is really painful. With VSS we would launch on demand and IDE would display in 3-5 seconds max and then they would close it when done.

This should be considered a bug and resolved, and/or at the least a slimmed down client should be offered. This needs to be fixed or stand alone IDE offered. Integrated is painful since developers often run with many integrated add-ins.. Resharper, DevPartner, NUnit add-inst etc.

Ben Ryan - MSFT wrote:

We cannot always tell whether a pending change's file was or was not part of the solution. For instance a pending delete of a file leaves no record behind in the solution that it was part of that solution. Therefore, we do a save of the solution's dirty files before checking in to make sure everything is sane. I believe the .sln file shows up in the list because VS associates open documents with the currently open solution via the "Miscellaneous Files" virtual folder. Interestingly, I could not reproduce the .sln being checked out if I said "Yes" to the save dialog. I'm running VS 2005 RTM with SP1. By the way there are some other workarounds that were not mentioned. 1) Save the file(s) in question manually before doing the checkin. 2) Close the solution before doing the checkin 3) Close the editor window for the file before checking in (which will prompt you to save the file). --Ben Ryan

I'm running with SP1. We do have people complaining ocassionally about the ide always asking to checkout the solution, often for no obvious reason as well. Sometimes even when there were no changes on a build, canceling the checkout still builds with no issues.

I don't like the fact it has to ask to save the solution for a file that was never included in the solution, there should be some way to keep track of that. Even if we let that one go, when it asks to save if I say NO it should not ask me to checkout and it should allow me to checkin my file.

I find this really obstructive to workflow since I often work on files not in the currently active solution.

Some issues with the workarounds:

1. I can't save the file in question, it is the solution itself and that will force me to checkout which I do not want to do.

2. I don't want to close the solution as I was in this case actively working on the solution and wanted to go right back to it after changing a file that was not in the solution.

3. There was no editor window to close (The solution is the full ide. If you are refering to the word document I was editing, that was closed).

I think either it needs to (A) keep track of what is or is not in the solution, or (B) allow overriding/bypassing the save and checkout (When I answered NO to save it should have let me checkin), and/or a (C) seperate slimmed down stand alone source control explorer needs to be available.

I think option (B) is really just a workaround and should be remedied by (A) or (B).

WXS123 wrote:

Ben Ryan - MSFT wrote: We cannot always tell whether a pending change's file was or was not part of the solution. For instance a pending delete of a file leaves no record behind in the solution that it was part of that solution. Therefore, we do a save of the solution's dirty files before checking in to make sure everything is sane. I believe the .sln file shows up in the list because VS associates open documents with the currently open solution via the "Miscellaneous Files" virtual folder. Interestingly, I could not reproduce the .sln being checked out if I said "Yes" to the save dialog. I'm running VS 2005 RTM with SP1. By the way there are some other workarounds that were not mentioned. 1) Save the file(s) in question manually before doing the checkin. 2) Close the solution before doing the checkin 3) Close the editor window for the file before checking in (which will prompt you to save the file). --Ben Ryan I'm running with SP1. We do have people complaining ocassionally about the ide always asking to checkout the solution, often for no obvious reason as well. Sometimes even when there were no changes on a build, canceling the checkout still builds with no issues. I don't like the fact it has to ask to save the solution for a file that was never included in the solution, there should be some way to keep track of that. Even if we let that one go, when it asks to save if I say NO it should not ask me to checkout and it should allow me to checkin my file. I find this really obstructive to workflow since I often work on files not in the currently active solution. Some issues with the workarounds: 1. I can't save the file in question, it is the solution itself and that will force me to checkout which I do not want to do. 2. I don't want to close the solution as I was in this case actively working on the solution and wanted to go right back to it after changing a file that was not in the solution. 3. There was no editor window to close (The solution is the full ide. If you are refering to the word document I was editing, that was closed). I think either it needs to (A) keep track of what is or is not in the solution, or (B) allow overriding/bypassing the save and checkout (When I answered NO to save it should have let me checkin), and/or a (C) seperate slimmed down stand alone source control explorer needs to be available. I think option (B) is really just a workaround and should be remedied by (A) or (B).

Having an available standalone simple non-integrated client like VSS's has been asked for by many members of our dev team, I think one should be available anyway to allow for these alternative workflows more simply. Launching other SCE windows in the same VS IDE likely would still be considered integrated and have this same issue. And has I said the heft associated with launching another full VS IDE is often too much to bare.

Ed Hintz wrote:

First, I agree a stand alone Source Control Explorer would be valuable. I will do what I can to have this considered in the product or at a minimum as a powertoy (sooned to be renamed to power tools). Regarding the original topic of this thread there seems to be two issues: Why is the solution getting checked out Why does TFS keep me from checking in w/o saving the solution file(s) The first issue has to be resolved by VS Core - TFS is told to check out the file because it was modified. This would happen regardless of the version control provider and we cannot ignore this request. Regarding the second issue, I can understand why you prefer the current behavior to change. However, this behavior is by design because the relationships between files not in the solution and check-in policies is not easy to determine. For example, suppose the solution has a custom build step that uses a common settings/target file that is not in the solution and the user has a Clean Build check-in policy. If we do not prompt to save the solution, the policy may not be able to tell a new clean build is required. Part of the contract with 3rd party check-in policies is that all pending changes have been saved when they are called to evaluate their policies. We call to evaluate policieis when the check-in dialog is displayed. Clearly, the specific scenario you described does not require the solution file(s) to be saved, but we are erroring on the side of caution to avoid data loss or scenarios where check-in policies do not work. Possible work arounds include checking in via the command line, closing the solution, or checkin via a seperate Visual Studio that does not have the solution opened. Another work around is your suggesstion of the stand alone source control explorer. Ed http://blogs.msdn.com/edhintz

Thanks for the info.

I'd say either SCE has to stop erroring on the side of caution and only require saving things it determines are part of the solution (I know that's not easy), or the stand alone source control explorer is needed. It is very common for developers to have workflow that causes them to need to manipulate files in source control that may not be in their solution. I.e. documents of varying sorts (requirements, bug handling/work item related or not), build scripts, binary checkins. I like the integration into VS IDE, but due to things like that and just the ability to have another source control window around I find that I want a stand alone to avoid these and other types of workflow impediments.

The workarounds certainly work, but as I mentioned are a bit problematic: Developers using VSS today typically never touch anything command line and don't know how to use it, Closing the solution a developer is working on and having to re-open it again is pretty heavy handy and if anyone is running resharper you know what I mean it takes a long time to close and re-open... not likely something a developer would want to do. Seperate IDE launch with resharper and other add-ins takes a long time (like a minute or more on our machines with add-ins loading) and soaks up quite a bit of memory.

Would definately appreciate the stand alone source control explorer if we can get launch times like that if VSS or better and avoid those integration issues.

Thanks,

Dave