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.
Related
I'm currently going through checking in changes I have made to my code. There are well over 100 files which have been changed, and I am repetitively getting this error for various files.
Could not find file '[File Path]'.
While I can understand the reasoning for the error, and I know on how I can fix it, how would I display all files which are throwing this type of error when checking in? Consider it to resolving merge conflicts, you would be given a list of files which require attention, you can easily see multiple and deal with them. Unfortunately while checking in changes, it only displays on error at a time.
The current process I am going through is Check In > Error Thrown > Fix Error and repeat. It would be so much more faster to be able to see all affected files and deal with them unlike the way I am currently doing.
I am using TFS 2015 on Visual Studio 2017 Enterprise.
Thanks in advance.
There isn't a good solution (at least not one I'm aware of) to the problem you are facing. Typically in these situations, I recommend to people to backup your changes to another folder and undo your changes in your working copy. From there copy back in the files you care about and if you renamed or delete files, make sure you do it through Visual Studio in either the solution explorer (provided your solution is correctly connected to version control) or in the source control explorer.
Another option is to try and reconcile the changes in source control explorer. You can use the tf command line tool to get a list of pending changes. Running tf status at the root of your workspace will give you a list of pending changes. You can then compare the output with what you have locally in the file explorer. Any files that need to be renamed or deleted should be done in the source control explorer.
As a side note, when using TFVC you should always do all of your rename and deletes through source control explorer to avoid this issue. Also, try to limit the number of changes you make between commits. Having over 100 files changed in one commit will quickly get you into a situation like you are in. Smaller, incremental commits are always preferred over large sweeping changes.
I want to migrate from star team 2005 to TFS 2010 with HISTORY. Is there any tool or any way where I can do it cost effectively. I know about Timely Migration tool, but it is too expensive.
There is no tool out there to do this. You are stuck with paying for Timely Migration or writing it yourself. Capturing history from StarTeam is extremely complex. The reason for this is because of what the view looks like historically. You can roll back the view to a point in time, and this alone works very well, but rolling back to every point in time where a change happened to the view is practically impossible to do using the API. This is because 1) not everything has an Audit record, so you can't use the audits, and 2) the audit records are purged, 3) there is a special feature to "play back" the history of the view to generate the listener events (requires MPX), but this will miss many events, 4) when items are shared, configured, branched, etc., these do not generate any audits in the project, 5) even if they did, getting every single change requires iterating through the view history down to the second to get all of the changes by analyzing the differences. So that means if your project has been active for a month and each time you analyze the two view configurations to diff them it takes 5 seconds, then actually migrating your project would take 5 months, and in the meantime it would be locked down.
So the next way to do this would be to establish "baselines" to compare. Using build labels is a good starting point if you have nightly or continuous builds in your project, or even just certain builds that were QA certified. This way you can use these baselines as points for diff/compare and then bring in the history that way. While this isn't as granular as a full history, it is by definition getting the most important differences to migrate over.
However, keep in mind that even doing it this way does not maintain the links between branch/merge points across the different branches/views. The only way to do this would be to go directly into the StarTeam database to get this information.
I went through all of these steps to try and write my own suite of tools to migrate from StarTeam to Subversion. It was fun and interesting and imperfect but had some promise, but ultimately never finished it. Part of the reason was because the time involved would have been far more than the value I got from it.
Which brings you inevitably to the most important question: what is the business value of maintaining full history? After going through this many times with project teams as a StarTeam administrator, more than 90% of the time it was readily apparent that the better approach is a cut-over. Make a time where you can begin working on new work in the new system and freeze work in the old system. It usually can be done with very little down time for the project team. You can even start by bringing over a history of Production releases to create a rough timeline in the new system. Use your existing comparison tools, either in TFS or BeyondCompare or elsewhere, to reproduce each state of your project source code, doc, etc. and reconcile it with your TFS project by checking in or deleting files as needed, and labeling your TFS project for each build you bring over. Line up all your TFS builds, work items, users, roles, etc, and make sure everything is ready. Then at time of cut-over, take the latest development snapshot from StarTeam over and do one more update to your TFS project. Lock your Starteam users out of the project (for checkins anyway), and begin working in TFS. Your TFS project will have a rough history of the most significant baselines and you will be able to keep your StarTeam repository open to users in case more history is needed.
One other thing to consider is how to create a permanent archive of your project. If your repository is small enough it is doable, but gets more time intensive the larger your project is. First, copy your entire database and vault to a separate instance and get that copy up and running. Then delete all other projects EXCEPT the projects you want to archive off. Run an online purge and make sure to run it to completion. You may need to restart your server and purge several times. When you are done, your entire repository should contain only the files and database records that are needed by your project. At this point you can back up your database and vault and keep them indefinitely. This reduces the size of your existing StarTeam repository.
Haven't used StarTeam in over 3 years but that was a fun ride back in time. Hope you found it useful.
Thinking about using Team Foundation Server with VS2012 or VS2013. Does TFS track every single local change? For example. If I save a file 10 times locally even though I don't check in, will every one of those local saves be checked in on the TFS server so anyone on the team can see? Of does it just send to the server the latest saved version of the file when you check in? I'm not looking for it to do this because it wouldn't seem to make sense unless a manager wanted to track your hours or something.
MSDN describes the checkin process over here. It is stated there, that...
... all the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
That means that only the last version of your changes made locally will make it into the changeset, onto the server and to your coworkers. You can save as often as you want beforehand, the server won't notice.
Short answer: No.
Longer answer:
I can't think of any SCM that works that way.
Here's how it works, with pretty much any version control system (the terminology will differ from SCM to SCM, but the concepts are the same):
You start modifying a file.
You change the file as much as you want. When you're done, you commit it/check it in.
The contents of the file at that point in time are what's stored in the SCM. No intervening changes are stored.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
I want to use a versioning system to back up and track my changes but I'm too lazy to check out/check in, merge, commit, etc. I don't want to branch, fork or anything else. I just want to be able to see what files have changes and what my Main() looked like last week.
So I'm looking for an application that will simply take my Visual Studio projects folder and back it up in such a way that all prior versions of the files are preserved so I can not only have a backup, but I can easily see how the file looked at some point in the past without me having to explicitly put it in a repository, update/commit/merge/etc.
Basically what I'm looking for is dropbox's functionality but on my local machine and without the 30 day limitation of prior versions.
Does such an application exist?
As AlexC stated, I highly doubt that the little bit of work you save by not using a version control system explicitly is worth the drawbacks, but anyway:
Simplest idea: Just write a wrapper script that checks out the HEAD of your repository, starts Visual Studio and commits everything to version control after you close it.
Alternatively, just trigger commits every hour. With most VCSes, non-modified files won't show up in the listing of modified files.