I am using Visual Source Safe 2005 and Visual Studio 2008.
##$% this Source Safe. With programs like Source Safe that ##$% up my data, who needs viruses, hard drive failure, and other assorted calamities.
My story starts with getting my workstation re-imaged on Monday this week. After the machine was re-imaged, I downloaded from Source Safe the source code I was working on. Thursday afternoon, I noticed that as I was working on my source code, the files were not being automatically checked out from Source Safe as I worked, however there was no problem saving my work on the disk.
So... I needed to check in my work. I noticed that the files (not checked out from Source Safe) were not read-only as they usually are, so I made them read-only.
I feel like I should have backed up my data locally at this point and I'm now kicking myself for not doing so, but the next thing that I did was I went back to Visual Studio to continue my work and see if I could get the program to automatically check out the files I was changing.
The first time that I began to edit a file (BigLongCodeFile.cs), it automatically checked out the file for me as I had hoped. However, in a split second it displayed a dialog that explained, "Your action caused a check out of file(s) BigLongCodeFile.cs, and a new version from source control has been loaded in the develpment environment. Please re-do your changes if necessary." And just like that, Visual Studio undid all the changes I had done to that file since Monday, representing hours of lost work for me.
It didn't prompt if I wanted to do this, just showed me a dialog informing me that the damage is done. With development tools like this, who needs a virus to destroy his work?
Is there some way to get my data back, or some way to avoid this?
The mistake was setting the flag back to read only, which was exacerbated by not making a copy of the files when you found things were not getting auto checked out from SourceSafe. Unless the new copy was written to a different location on the drive, which is unlikely, you are currently hosed. If it could possibly be saved elsewhere (note I am talking physically saved, not logically saved (ie, what you see in Windows Explorer == logical)) you can use an undelete utility. It is a long shot, but you can try undelete tools; I would not hold out much hope.
One of the first things to do when you find source control is not working correctly, and you have altered files, is to make a backup of the folders you have worked on. A simple copy of the structure to a temp location is good enough. Then fix the source control issue and be prepared to consolidate your efforts. There are tools for this, if you are worried someone else might have edited files.
As for why VS did not warn you? The file was flagged as if it was not changed. VS noticed something after the save operation (size change, most likely) and warned you something was in error.
In the past, I have been burned by trying to second guess software, so I know the pain. That is why copy backup is a good practice when you notice something strange. This is less problematic in TFS, but I would imagine it might just overwrite a file that appeared to be checked in (read only flag set) as well.
Related
Our development team is currently working on a project in Visual Studio Professional 2015 that involves forms, etc. As it stands, the master code is stored on an individuals desktop but a copy can be found on a shared drive as well as my personal hard drive.
We just encountered a very serious issue. I made changes to my copy on my personal hard drive and when I arrived at work, was made aware that my change had in fact changed the master code. This will prevent anyone from being able to experiment with the code at all, anywhere.
Has anyone ever experienced this and if so, do you know of any way to make it stop??
From the responses, no one else has heard of this happening or even knew it to be a thing, so creating backups of the code should have been sufficient. Using a VCS is not the only way. Without the VCS, we are and have been creating backup copies of all coding. The problem becomes if I'm attempting to make an update to test in my copy of the code, it's updating all copies - never in the history of any coding/application have I ever seen this.
The copies I am referring to, is literally a copy. I copy the project, then put it in another folder on my hard drive. It makes no logical sense to me or the team how or why a copy is updating the master and vice versa.
I guess the only solution as this point is to use a VCS. I would like to know why and how this is happening regardless because we were only lucky that this was a simple line of code that was changed and not a massive overhaul!
I have a project that is source controlled using TFS. I was doing some coding on my laptop when, unfortunately, my computer crashed and I ended up having to re-install Windows. I was afraid that all my code would be lost, but thankfully I was able to restore the code files.
My problem is that now I need to commit the changes to TFS. Currently the projects do not have any source bindings. I can't overwrite the current code base because there is work that has been done since my crash by other devs.
How can I add the changes I've made to TFS?
The way i've done something like this is kinda hackish, but what i usually do is get latest from TFS onto my laptop, and checkout all of the code from the project in question. Then i take the changed code and copy it over that folder, check it in. TFS should be smart enough to only really affect the actual code items that have been changed. You can see in the history the actual files that got changed to be sure.
If you know the exact files that you need to update, then that will make things much easier, because you can do the above steps, but then just check out the particular files you know of. You can do a compare between them and your new code to make sure that you don't overwrite anything your other programmers have done. Again, hackish, but i don't know of any streamlined way to do this.
You might want to make sure that you download the TFS visual studio extension, since that will give you rollback capability.
Question: Today I worked with MS Visual Sourcesafe, that is to say Microsoft's Sourcecode destruction system, which has never ever saved anything, but already destroyed much.
Today I had one more of those nasty destructive episodes:
I was working on a reporting service report (*.rdl xml files).
I was modifiying a report, so I created a copy and modified it.
The original being named FILENAME.rdl
My modified copy being named FILENAME2.rdl
I finished, saved. Checked in.
It was all correct.
I switched offline, continued to work.
Later on, I deleted filename.rdl, and renamed filename2.rdl to filename.rdl
I continued working for the rest of the day offline.
In the evening I checked in, and filename2.rdl reappeared.
I thought it had copied the old version back, so I deleted filename.rdl (from local computer and sourcesafe, via the delete keyboard button in the visual studio treeview) and wanted to rename filename2.rdl again to filename.rdl.
When I tried, I realized that filename2.rdl was just an entry that appeared in the treevieww, but not on disk... It was in that very momement that I realized that I now have a problem...
I looked in the recycle bin, but nothing there.
I tried 5 different undelete programms, and shadow copy explorer [to find out that non C drive data - such as the data partition e - is not backed up by the shadow copy service automatically...], but no luck. The file is gone.
Is it possible to still retrieve the file from sourcesafe, or does it get permanently removed when one presses the delete button in VisualStudio treeview and clicks OK on deleting it from file & sourcesafe ?
So far I found this one:
http://support.microsoft.com/?scid=kb;en-us;244019&x=11&y=7
but from that it is unclear whether the file is gone.
The problem is if it isn't there, I should redo the about one hour work this evening, because tomorrow will be a busy day.
There are 2 levels of Delete in SourceSafe. When you delete the file, if you check the "Destroy permanently" option, the file will not be recoverable. Otherwise, you can go to the Properties of its parent project and recover it later.
If it's not stored under some different version or branch of your code, I think you're out of luck.
Regardless, however: you estimate this is one hour's worth of work. You already (presumably) spend some amount of time (probably an hour or two) trying to get the file back. Are you not now at the point where, even if VSS has a way to get your file back for you, you'd be better served just rebuilding it?
Short answer - definitely NO!
It can't! I tried.
But it overwrote the recreated report with a completely wrong recovered version...
Fortunately, I've forseen this, and made a backup copy of the recreated report for this case.
So I didn't spend that one hour of recreating the report in vain.
This program should be forbidden, with noncompliance to this prohibition being subject to the death penalty.
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 just wonder what the best approach is to have multiple users work on a Project in Visual Studio 2005 Professional.
We got a Solution with multiple Class Libraries, but when everyone opens the solution, we keep getting the "X was modified, Reload/Discard?" prompt all the time. Just opening one project is an obvious alternative, but I find it harder to use as you can't just see some of the other classes in other projects that way.
Are there any Guidelines for Team Development with VS2005 Pro?
Edit: Thanks. The current environment is a bit limited in the sense there is only 1 PC with RDP Connection, but that will change in the future. Marking the first answer as Accepted, but they are all good :)
What you need is source control.
You should definitely not open the same files over the network on multiple machines. For one thing, Visual Studio has safeguards in place to prevent you from modifying certain files during a build, but it has none of that that will prevent others from modifying the same files over the network.
By setting up source control, each developer will have a separate copy of the files locally on his or her developer machine, and periodically communicate with the source control system to check in/commit changes. After that, other developers can ask for the latest updates when they're ready to retrieve them.
Use source control to keep a central repository of all your code. Then each user checks out their own copy of the source code and works locally. Then submits only the code that changed.
https://en.wikipedia.org/wiki/Version_control
A number of people have recommended using source control and I totally agree. However you also need do the following.
Exclude your personal options files from the repository (eg your .suo files)
Exclude your App.config files from the repository. - Not entirely but you need to have a Template.App.config. You commit that instead, and only copy your App.config into the Template.App.config when you make structural changes. That was each user has their own individual config for testing.
There are probably some other files worth excluding (obj directories and so forth) but thats all I can think of right now.
Peter
This might sound snide, but if you're opening up the solution from a shared location then you're doing something wrong. If that's the case then you should start using source control (something like Subversion) and have everyone check out a copy of the project to work on.
However if you're already using source control, then it might be a symptom of having the wrong things checked in. I find that you only need the sln, and the vcproj under source control.
Otherwise I don't know...
You should definitely, definitely be working with source control!
This will help stop the collisions that are occurring. Also, if you are making changes to the shared projects this often that it is a problem, then also ensure that all code is tested before getting checked in (otherwise they may bust someone else's build), but make sure they check in often (or time gained from not dealing with prompts will be lost in merging conflicts) :)