I have a project that I have been using VSS source control from the VS Pending Checkins tab. This has been working until recently. Now when I make a change to the code, I do not get an entry in the Pending Checkins tab.
I saw this article, but did not see a Go Online option either when right-clicking on the solution or under File -> Source Control. Probably because that person was using TFS rather than VSS.
I tried breaking the source control links and creating a new tree, but it still didn't check out automatically when I made changes. I have been using the Check Out For Edit option, and then checking in, but this gets all classes whether I make changes or not. I use source control in VS because the list makes it simple to determine whether I need to check something in or not.
Does anyone have an idea as to why this may have stopped working with this project. It is still working in other projects. I do have "Check out automatically" selected for On Save and On Edit. Allow checked-in items to be edited is not checked, nor are any of the other options under Source Control -> Environment.
Thank you for any suggestions you may have.
UPDATE: I just added a new class to the solution, and that class appears under pending checkins. However, I also made several changes to other classes, and none of them are appearing under checkins.
I too rely on SourceSafe via Visual Studio to automatically check out files. But it usually just works by default although with certain assumptions you need to know that I learned from this post which explains the risky methodology:
If you Get all files without checking them out then the files will be read only as you can see in Windows Explorer properties. Then, when you type your first edit to any file, VS/ VSS first checks for the read-only attribute on that file. If it is read only then the file will be automatically checked out (this is the default option). Then, when you are ready to check-in a set of files, VS will show you all “Pending Check-ins” and you can check them in as a set.
I have relied on this for years as it has been working great for me in our environment until a few weeks ago when many of my source files lost their read only attribute somehow. So without read-only, some of the files were not getting checked out and therefore not getting checked in. And that’s really hard to detect until your hard-drive crashes and you try to build from another machine!
And I found a method here to fix the read only attributes:
check in all files that were edited (used VSS to find out which files where
changed [using differences] even though VS did not checked them out). Then did a Get Latest with
overwrite of local files and made sure the "Keep writable" checkbox was not
checked.
Related
I changed a lot of files in one of my ASP.NET Solutions and checked-in. Afterwards I realized I wanted to role back to my original files. I am aware I could have just went to Source Control explorer and rolled back the changeset but I went about it wrong. Since I took a backup of my entire project directory prior to doing this I figured it would be easy to simply just replace the directory with my backed up files.
After replacing the entire directory with the backup and When I open the solution I get the following message:
One or more source control bindings for this solution are not valid
and are listed below. Source control bindings can be modified by
selecting File, Source Control, Advanced, Change Source Control from
the main menu.
Then all of the .csproj files are listed below.
I followed the instructions that I saw on many websites saying unbind then rebind and it is not doing anything for me.
My first question is why did this happen if it is the same exact set of files that have all of the source control bindings.
My second question is how can I go about getting this backed up solution in source control again?
I expect it to be in source control showing me the pending changes so that when I check-in the latest version in source control will be my replacement version.
Unlike windows file system, you shouldn't simply copy and past the backup files. It will definitely cause source control binding conflicts as you encountered.
You should use rollback entire changeset feature. This will influence your source control in TFS. If you roll back a file to an earlier version, tfs will eliminating the effect of all changesets that occurred after that version. More details please take a look at this tutorial: Roll back changesets
Since you just need to go back the old version files, you could now roll back your changesets to the one you back up the entire project. Check in the roll back operation.
Another way is as below if unbind/re-bind the project is not work:
Unbind project in Change Source Control
Unload project in Solution Explorer
Reload project in Solution Explorer
Note: If you use above option, the TFS consider all project files as newly added files to the solution.
I'm developing in Visual Studio 2005, using TFS as the source control. Whenever I haven't been working on the solution for a while, I always do a recursive Get Latest in Solution Explorer.
However, this doesn't always seem to work. If I know I don't have the latest version of a file, even right-clicking this (in Solution Explorer), choosing Get Specific Version and ticking the "Force get" box doesn't work.
I seem to need to open up the TFS Source Control window, and there force a Get of the file in question.
Also, the Solution Explorer often has the little "checked out to someone else" icon next to files, but when I check in Source Control, they're not checked out at all!
I'd just like to know if these problems are widespread, whether they persist in VS2008 (I haven't used TFS for a big project in 2008 yet), and if there are any fixes or workarounds.
1) I would not make a habit out of Get Latest from Solution Explorer. Even if it always worked 100% bug free, it is far slower and less reliable than doing it from the command line or Source Control Explorer. SlnExp has to crawl your whole project structure and issue non-recursive calls...pseudo algorithm:
parse sln file
foreach project in sln
TFS_GET makefile
parse makefile
enumerate sourcefiles[]
TFS_GET sourcefiles[]
loop
SCE requires no parsing and issues one single recursive webservice call. In addition to the performance gain, this is much safer:
(a) Build-time dependencies aren't always part of a project's file list. Executable tools, 3rd party assemblies, and deployment scripts are all common examples. SCE will download them, SlnExp won't.
(b) Scoping Get calls down to specific files won't yield the expected result when a file is renamed or moved. At best, the "old" name is deleted from disk; at worst, nothing appears to happen at all. (this may be the cause of the bug you reported) In order for a file to truly be renamed/moved in sync with the server, the old & new paths must both be inside the scope of the Get.
2) There have been many bug fixes to the SlnExp "glyphs" over the years. I won't claim that VS2008 SP1 is perfect in this regard but it is definitely improved.
Sometimes Get specific version even checking both checkboxes won't get you the latest file. Most commonly what happens is that you've made a change to a file, and you want to undo those changes by re-getting the latest version. Well... that's what Undo pending changes is for and not the purpose of Get specific version.
If in doubt:
undo pending check in on the file(s) before you do 'get latest'
do a compare afterwards to make sure your file matches the expected version
run a recursive 'compare' on your whole project afterwards to see what's different
keep an eye on pending changes window and sometimes you may need to check 'take server version' to resolve an incompatible pending change
And this one's my favorite that I just discovered :
check the Output window for messages such as this :
Warning - Unable to refresh R:\TFS-PROJECTS\www.example.com\ExampleMVC\Example MVC\Example MVC.csproj because you have a pending edit.
Yes this critical message appears in the output window. No other notifications!
Nothing in pending changes and no other dialog message telling you that the file you just requested explicitly was not retrieved! And yes - you resolve this by just running Undo pending changes and getting the file.
I and another developer are working on the same VS 2008 project using Source Safe. If one of us needs to add a new item, the person who doesn't have the csproj file checked out gets a message that they can't add because csproj and vspscc files are checked out.
Is this the normal behavior of Source Safe? What's the workaround beside asking the person to check in or to use another source control software?
You can turn off exclusive checkout in SourceSafe via the Options dialog, Allow Multiple Checkouts checkbox. This will allow you and your co-worker to both have the .csproj checked out at the same time. However, if you both make changes, you will need to merge those changes when the second person does their check-in -- and SourceSafe has notoriously weak merge tools compared to other version control systems. So although multiple checkout can be a lifesaver, you'll still want to avoid it where possible.
That was 'normal behavior' back when I used VSS in 200-2006 time frame. There might be some options in VSS to turn off "exclusive checkout" which would let both of you check out the file at the same time, and whoever checks it in 2nd has to do a merge.
This is driving me crazy and has resulted in lost work (not much, at least).
Normally, when I edit a file in Visual Studio, it's supposed to automatically check that file out in source safe. On multi-project solutions (e.g., web app with class libraries), sometimes none of the files in one project would automatically get checked out, though exiting & reloading visual studio may fix that problem temporarily. Furthermore, project files are never automatically checked out. Whenever I add/remove code files, I have to remember to explicitly check out the project file as well (otherwise we'll have issues with code files not showing up in the solution explorer, or trying to load non-existing files).
We're using VS-2008 and VSS 2005. Do you have any idea how I might fix this? There are no more visual-studio updates/fixes on Microsoft Update.
You need to ensure the files are read-only, or VS won't be able to tell that they are version controlled (or, at least that's what it uses to determine it). You can tell VSS to set itself up so getting the latest version places the files RW on disk.
There may be other problems here, but that's what comes to mind first. My advice (that I took myself) is to migrate to SVN or an alternative. Losing work is unacceptable.
I have a VS2005 solution which contains a variety of projects (C++ DLLs, C++ static libraries, C# assemblies, C++ windows executables) that are combined in various ways to produce several executables. For some reason, every time I open the solution, VS2005 wants to check out one of the projects for editing. The project is not modified in any way, it's just checked out. If I configure VS2005 to prompt before checking out, I can cancel the auto-checkout during load with no ill effect that I can see. It may or may not be relevant, but the project it keeps checking out is cppunit version 1.12.0 (the static lib version). How can I stop this annoying behavior?
Other potentially relevant (or not) details:
Source control is Team Foundation Server (not Visual SourceSafe)
no .suo or .ncb files are checked in
the .vcproj and .vspscc files are being checked out
When I close the solution or shut down Visual Studio, I'm asked whether I want to save changes to the project. Answering yes results in no changes to the file (Kdiff3 compares my local file to the server version and reports"files are binary equal")
Attempting to check in the "modified" files results in a Visual Studio message saying "No Changes to Check In. All of the changes were either unmodified files or locks. The changes have been undone by the server"
As Charles and Graeme have hinted at, Visual Studio constantly make changes to user option files and such on the backed even if you don't make changes to the project directly.
I'm not sure what information is being stored but I do know that it happens. Common remedies is to not include the *.suo files. I also don't stored anything in the bin or obj folders in sauce control as this can have a similar effect as your talking about (if you build). (Checks out the project upon a build. Thought this does take an action to happen).
Overall it is unavoidable. It is just how VS2005, 2008 work.
Does this answer your question?
Regards,
Frank
There are two reasons I've encountered that cause this behavior.
The first is old source control bindings. If you have a project that used to be managed by another source control tool, it might have leftover bindings in the project file. Open the project file, and change the following settings from something like this:
SccProjectName="$/Team/Platform/Projects/MyProject"
SccAuxPath="http://teamFoundationServer.example.com:8080"
SccLocalPath="."
SccProvider="{88888888-4444-4444-4444-BBBBBBBBBBBB}"
to this:
SccProjectName="SAK"
SccAuxPath="SAK"
SccLocalPath="SAK"
SccProvider="SAK"
Different project types are defined in different ways. The above example is from a .vcproj, C# projects are in XML, VB looks like something else, but the meanings are the same. Simply set all four values to the constant string "SAK" and Visual Studio will automatically handle source control. See Alin Constantin's blog for details.
I haven't yet discovered the root of the other reason, but the project that is giving me trouble is also CppUnit 1.12.0! I'll keep digging and post my findings.
John
Have you put a .suo or .ncb file into source control perhaps?
Have you tried closing VS2005 after it checks out cppunit and then seeing if any changes were made?
I often encountered something like this with Web App solutions where the project file wasn't actually saved until you closed studio down and reopened it.
Just to clarify, I'm assuming that you mean Visual SourceSafe2005 is causing the problem, not Visual Studio. (FYI, Visual SourceSafe is usually abbreviated VSS.)
I've experienced this issue with VSS before. I think the limitation is really fundamental to Visual SourceSafe: it's just not that good of a product and I would move to something else if it's a decision you can influence.
If you can move to something else, I recommend Subversion for a small or medium-sized project. It's free, and does not use the pessimistic locking mechanism that Visual SourceSafe uses by default. There's an excellent Visual Studio add-on called VisualSVN that will give you the same functionality in the IDE (seeing what files have changed, etc.) that you get out of the box with VSS.
If you cannot change source control systems, I believe Visual SourceSafe has a mode called "non-exclusive checkouts" or something like that that uses the optimistic locking that Subversion and other source control systems use. Try setting that option at least for the files that are obviously not being changed and see if that resolves the issue.
I get this a lot when one of the projects in the the solution has source control information with path information that is not the same in source control as on your workstation. When VS opens the project it will automatically attempt to check out the project in question and
To fix it, you're best off having everyone who uses the project remove their local copies and do "get latest version..." to grab what is in your source control database.
you can also check the .sln file and look in the GlobalScxtion(SourceCodeControl) area for each project's information and see if the relative path is not how you have the projects stored on your workstation - though manually changing this file vs. doing a "Get Latest Version..." is much more likely to cause problems for the other developers who use the solution as well.
Your cppunit project is probably automatically creating one or more additional files when the project first loads, and then adding those files to the project. Or else one of the project's properties is being changed or incremented on load.
If you go ahead and check the project in, does it check itself out again next time you load it? Or does checking it in fix the problem for awhile?
Very often this sort of behavior is caused by VS trying to update source control bindings.
Graeme is correct, VS will not save project or solution files until you close VS.
I would let VS check the files out, then close VS, then diff them.