As I was wrapping up my work-day, I wanted to shelve my changes in TFS before I went home as I encourage all developers to do. All my changes were saved to disk, and I had a number of SQL query windows open that I'd been using as scratch-pads to write queries against the database.
Unfortunately, it wouldn't let me shelve my legitimate changes without saving these files to disk - and I have no intention of saving them, they're just scratch-pads to mash out some SQL queries.
Is there a work-around for this? The queries are never saved and have never been added to source control.
Related
In some Visual Studio 2015 projects that I have, there is a *.VC.db file in the project folder, named after the project: If the project name is FooBar, then the file is FooBar.VC.db.
This file looks like a database of some sort, but I'm not using any databases at all in the projects.
My best guess would be that it is operating similarly than the HelloWorld.sdf database, which is used by IntelliSense.
Is it the same just in "new", or is it doing something important and I shouldn't delete it?
This happens after you installed VS2015 Update 2. The projname.vc.db file is the new IntelliSense database, it replaces the old projname.sdf database. Not otherwise by deleting that .sdf file. You may also see a hidden projname.vc.vc.opendb file, a lock file to indicate that the dbase is in use. Crystal ball says that somebody is bound to have to delete this one by hand sooner or later.
This was already available before but was experimental. Now permanent. Promises are for a rough x2 speedup of IntelliSense. Biggest change appears to be switching to another dbase engine, now using SQLite instead of SQL Compact. Powerful open source confidence vote there :)
Don't delete the file just yet or next time you open the project IS is going to be catatonic for a while. Well, not as long as before :) You'd consider cleanup, if at all, when you're done with the project. Go ahead and delete the .sdf file, it will no longer be used.
We have multiple developers on our team. This works for everyone except one developer, but we cannot seem to find the reason it does not work for this individual. We all have VS premium+, TFS 2012 power tools installed.
We have a branch. We get latest version from branch. Go to windows explorer and delete all files in folder "sdk" (there exist no subdirectories in sdk/). Then we copy into it a bunch of files. (This effectively leaves some files as new files, updated files, identical files or removed files when compared with what was deleted.)
When we go to pending changes, these changes show up under "Excluded Changes - Add(s) 51, Deletes(3)".
Except for one developer. His system does not recognize these changes. What might cause this to not work for him?
If it helps troubleshoot, he is also the only developer that if he were to delete these files via power tools delete option in windows explorer, his .dll files get locked. This does not happen for anyone else either.
This is what we've checked so far:
EDIT: Solution Found - Thank you all for the responses! It was indeed the local vs server workspace option. Setting his workspace to local solved these and a few other issue he was apparently having.
Make sure that the developer is using a "Local Workspace" as opposed to the "Server Workspace".
This is a concept which was introduced in TFS 2012 which helps developers to work offline as opposed to server workspace in earlier versions which did not allow that. TFS 2012 changes up the workspace options. Server workspaces are still available, and work exactly has they have in previous versions. However, TFS 2012 now contains a new type of workspace, called a Local workspace. Again, this is an oversimplification, but in a Local workspace, all the files are read/write, not read-only. The meta-data about the files is stored in a hidden folder in the root of the workspace, which allows edits, renames and deletes to be done locally without any communication to the server.
This improves the offline story with TFS significantly, as you no longer encounter issues with editing read-only files. It also makes it easier to work with other tools (such as Notepad) to edit code files. Making a change to a code file using Notepad will still mark that file as edited, which will be picked up by TFS the next time you connect.
LINK
This only ever happens when a user tampers with a local view of source control (be it a local workspace, or not). If all you ever did was get latest from TFS this would never occur, instead, the local view of what is in TFS would always be properly managed.
Also sounds like a bad merge, e.g. getting latest (where the files no longer exist) then copying in old content (introducing untracked files.) One thing you might try doing to correct the issue is doing a forced fetch from TFS after deleting the local workspace contents BEFORE attempting a merge. This will ensure that the local workspace is up to date an accurate with what the TFS server believes is truth, if it still occurs after merging in content then the problem is almost certainly within the merge process the user is going through (i.e. PEBKAC, or a knowledge gap about what they are doing.)
If you unshelve old content (pre-deletion) into the local workspace (where the deletions have already been performed, according to the SCC, and thus locally because of a sync/get-latest) then the unshelved files will effectively become untracked and it's up to the user to clean up the mess. This is identical to a user having copied loose files into their workspace that TFS never had any knowledge of. TFS isn't going to prune untracked files for you, I believe some other source control tools might do this as a configurable default, TFS does not.
That this is only happening to one developer in the team suggests that the other developers, one at a time, should sit with this developer and drive using "their process" to see if it still occurs for them. More often than not this comes down to a bad process a user has adopted, and putting a different person in the chair can help highlight why it has been occurring and help end it. A disciplined build/source manager and/or developer should not experience this problem.
Very interested in knowing what the problem turns out to be.
I canno't view the history for a certain file in VSS. Erery time I click on 'view history' or rollback or even the difference between two files, I get this error :
SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your sourcesafe database.
I am trying to view the scripts that I added in the early morning, but I am not able to do that. I so in need them. what should I do ? is there a quick fix for it ?
I should mention that I am able to view the history of the new files that I added lately.
VSS uses a pair of files for each instance of a file in the database: one representing the latest version of the file, and one that represents the change history. The error message is accurate. Perform maintenance on the database. In my experience do this monthly, along with frequent backups. If you don't have a recent backup, it is likely that you have lost the history for the file, but may still have the latest version.
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.
I usually create a solution folder in Visual Studio and put my DB scripts in them. I always use at least this set of scripts:
Drop model
Create model script
User functions
Stored procedures
Static data (lookup tables)
Test data (not deployed)
Then I simply combine them and run against an SQL Server so I'm able to recreate the whole DB in a single step (by combining these scripts into a single one and executing it).
Anyway. I've never used projects in either:
Visual Studio or
SQL Management Studio
I've tried creating SQL Server 2008 Database Project in Visual Studio 2010, but I'm somehow overwhelmed by all the possible server settings (which I prefer to stay default as set on the server anyway). So I'm a bit confused: Should I use this project template or should I just do the same thing I always did?
What do you use and why? What are advantages I may benefit from by using either?
If I were you I would continue to do it the way you are doing it. In fact I do! The advantages of having the actual .sql files right there in a folder for you to use/edit/look at in my opinion are far better than the advantages you get by using a DB project. DB Project would be used if you were doing something like Storage Reports, were you have to communicate with like 8 databases and compare then to 8 different databases and save result sets etc... Now don't get my wrong there are advantages of Database Projects, I just don't think they are actually doing much help when you have such a simple setup that works already.
Advantages of the SQL Server 2008 Database Project in VS10:
Not having to switch back and forth
from your current client you use to
communicate with your SQL server.
Decent Data and Schema compare tools.
Gives you a one-click way to reverse
engineer a database into source
control, and keep it up to date.
You can compare projects to physical
databases and vice-versa. (This makes it pretty easy to keep your database up to date, no matter where you make change it: file system database project, or in the physical database itself)
If the current tool your using is not specifically tailored to SQL Server, this one is.
Extremely helpful if you need to do
unit tests directly on the database
without using abstractions.
If you're looking for something a little less complicated, you might want to try SQL Source Control. This won't even require you to maintain scripts, as it doesn't this for you behind the scenes. It will, however, only work as a solution for you if you use either TFS or SVN. And it costs $295...
It has a 28-day trial period, so if you're happy to try it out, I'd be interested in your feedback.