This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Get all files from VSS for a given date?
I need to get a complete project recursively as it existed on a specified date in the past. How can I do that without having to look at and selectively recover each individual file? Source Safe 8.0
Actually, it might be possible. Here are instructions I received from a co-worker (thanks Bruce!) for doing just that with SourceSafe 6:
In the VSS database, select the top-most project (not an individual file in the project) that you are interested in.
Get the history for that project, making sure that the "Recursive" and "Include file histories" check boxes are selected. The "Include Labels" check-box is optional, but you definitely don't want "Labels only."
Select the file / date you're interested in from the history list box.
Click the "Get" button.
Click the "Yes" button on the pop-up dialog that asks, "Get the entire project containing this file version?"
Hope this helps (for next time).
If that particular version was not branched out or labelled, I believe you have no choice but to manually check and recover each file from Visual Sourcesafe.
More information on labelling and branching and sharing for Visual Sourcesafe over at MSDN.
If you have a choice of using another SCM, I would recommend using Visual SVN to integrate an SVN Server with Visual Studio.
Related
This is not a duplicate of an existing and answered question, like this one.
It is well known that VS pending files list shows all checked-out files, some of them might have no edits at all. And the recommended solution to remove those files without an edit is to run a TFS Power Tools command, as answered here.
However, this doesn't apply to the files that were changed (by a mistake, or on a purpose), but the change was manually reverted. In other words, if the content of two files is binary (or literally) the same, the "Undo Unchanged" command might still think the file has changed and does not remove it from the list.
Is there any way to force TFS PT to perform content-based comparison for pending files vs. latest server version?
Use local workspaces instead of server workspaces (on VS/TFS 2012 or later). With local workspaces, the only things that show up in the "Pending Changes" window are actual modified files.
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.
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.
I'm using Visual Studio 6.0 and Visual Basic 6.0.
I have them integrated but when I check out a Project and then try to edit a module in that project it's locked and I have to manually right-click on it and do a Check Out to unlock it.
I thought there was a way to have VSS automatically check out the file for editing.
Any suggestions?
I agree with kris here. Now I know that a bunch of folks saying your "software stinks" doesn't really answer your question. But there is a world of difference between a check out style source control and a file locking system like Source safe. The general consensus is that Check out systems are far superior.
With check out, what you do is you check out the project from your repository. All the files are editable. You work on your project as normally. Then before you checkin you do another update. If anybody else in your team did a update the software will automatically merge in the changes into your code. You will have a chance to review the merges and resolve any conflicts. After the update you can then check in your changes which everyone else can retrieve.
The big scary part is the merging part. Back when CVS and subversion where just command line tools it was a little scary as it was a pain to retrieve what happened with the merging. But with today's tools like Tortoise is all visual. In the last couple of years I can't think of any instance where a automatic merge failed. Any conflicts (basically two people edit the same line of code) are display right here for you to resolve.
Subversion
Tortoise SVN
There is an option in SourceSafe under the "Local Files" tab labeled "Use read-only flag for files that are not checked out". By default this option is selected, but if you unselect it, you will be able to edit any file in the project without checking it out.
Once you uncheck the option, you can get the latest version of a project to remove the read-only flag from all the files.
When you check out a file, you will be warned that there is a writable copy of the file in your working folder, at which time you can replace it with the version in the SourceSafe database.
I never figured out a way to do this. It was always a huge pain. Sorry for posting a negative answer, but I figured that you might want to know that you aren't alone in hating this, but that there wasn't an immediate and obvious answer. I'll be following this question along with you in case someone out there does know of a solution...
I don't think it is possible to do this (at least it wasn't when we used VSS eight years ago), but while you are experiencing the pain of a check out styled source control, run - don't walk, to some real, non-locking style source control solution. SVN, CVS, Git, Mecruial, anything that doesn't lock files, and doesn't leave your source in a proprietary file sytem. We switched to CVS eight years ago because we lost all of our source history (the code was checkout out so it was retrievable), due to a VSS glitch. Best thing we ever did, made collaboration ten times easier. Now CVS isn't the best solution (it was the most reasonable solution for windows back then), but anything is better than VSS.
Best solution I found was to check out all the files. Took a bit of poking around to figure out how to do that. Here's how:
How to check out all VB6 Project files from VSS?
when I check out a Project and then
try to edit a module in that project
it's locked and I have to manually
right-click on it and do a Check Out
to unlock it
Like it or not, it works that way by design i.e. you can check out all the files but you have to explicitly choose to do so, rather than being the default option. I guess that's because checking out all modules (class modules, forms, usercontrols, etc) locks out all other users from the entire project, which is normally undesirable in a team collaboration environment.
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.