I'm trying to convert a small project from VSS 2005 to TFS 2010 and all works well except all history is not converted. I'm following the walkthrough from http://msdn.microsoft.com/en-us/library/ms253060.aspx (Migrate from Visual SourceSafe - Visual Studio 2010) very closely.
I backup one small project from a huge VSS database to my local machine, prepare the settings.xml file, run VSSConverter in analysis and then in migration modes and the code ends up in TFS, the projects structure is correct, just the history is not there.
After conversion, I have a number of errors in the VSSConverter.log file which look like this:
[VSS, Error, 3, 2012/01/04 14:48:02.159] Exception: System.Runtime.InteropServices.COMException
Message: File or project not found
Stack Trace: at Microsoft.VisualStudio.SourceSafe.Interop.IVSSItem.get_Versions(Int32 iFlags)
at Microsoft.TeamFoundation.Converters.VersionControl.Vss.VssWrapper.ReadHistoryItemNoRecursive(ItemInfo itemInfo, Int32 flags, String spec, String name, Boolean type, Boolean deleted, Boolean isPinned, Int32 pinnedVersion, Boolean writeToDB)
at Microsoft.TeamFoundation.Converters.VersionControl.Vss.VssWrapper.PutInfoInDB(ItemInfo itemInfo, Boolean isMigrate)
Help Link: ssusexp.hlp#10609
BaseExceptionMessage: File or project not found
I tried to search for more info on these errors but there's not much information. Had anyone seen these errors?
Thanks.
I think I found out what I was doing wrong and can now reproduce the behaviour.
My original VSS database has the following structure
$/
___+Folder1
_______+Project11
_______+Project11
...........
_______+Project1n
___+Folder2
_______+Project21
...........
_______+Project2n
and so on. If I backed up and restored Project11 to an empty VSS db I hade the following:
$/
___+Folder1
______+Project11
Now, when I placed
<Project Source="$/Folder1" Destination="$/Project11"></Project>
into my settings.xml, I was losing history, even though all code was converted properly.
When I changed that to
<Project Source="$/Folder1/Project11" Destination="$/Project11"></Project>
all history gets converted.
Maybe that helps someone. :)
My experiences: We migrated from TFS2005 to TFS2008 and then to TFS2010. As far as I remember, there were issues during migrating to TFS 2008. We used migration tool to migrate all changeset from TFS2005 to TFS2008 database (per changeset)(to save history changes). It was really slow process. It was not possible to do it in one day window, so we decided to move whole repository to the new TFS DB (to not block developers to make check-in their code changes). We lost all history changes, but we were migrated :) and developers were not blocked. It was not my responsibility. I did not make this decision. We used some tool from codeplex for it. Maybe this one (I don't remember now sorry). Migrating from TFS2008 to FTS2010 is no problem at all because you can use the sam DB for TFS2010 and your history changes should be untouched.
I know this is not an answer for your question, but it may be helpful for someone to not do it this way :)
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.
I've experienced issues with database growth with the berkeley db while awfully using svn as a library repo.
Now we are evaluating TFS. which as a code repo some people could favor it or not, but it works, and it does what we need it to do fine.
We need to store somewhere the compiled build for auditing issues when going to several environments (QAs, Prods, etc) to ensure it's exactly the same file.
My boss says that we should store them in TFS because of the plus value of revision history ("and other stuff which TFS offers"). But I disagree, a Code Repo should be to store Code. And to store the builds we should use a Filesystem, because...
We'll be storing stuff which in some time from now will be deprecated and noone will use, while in a filesystem we could develop a batch process integrated with the tfs msbuild which could do a weekly cleaning or something.
Indexing, backuping and other stuff could very well be done by winServ2008 normatives...
But maybe you could tell me better, which is the optimal way?
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.
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.
In Team Foundation Server, I know that you can use the Annotate feature to see who last edited each line in a particular file (equivalent to "Blame" in CVS). What I'd like to do is akin to running Annotate on every file in a project, and get a summary report of all the developers who have edited a file in the project, and how many lines of code they currently "own" in that project.
Aside from systematically running Annotate of each file, I can't see a way to do this. Any ideas that would make this process faster?
PS - I'm doing to this to see how much of a consultant's code still remains in a particular (rather large) project, not to keep tabs on my developers, in case you're worried about my motivation :)
It's easy enough to use the "tf.exe history" command recursively across a directory of files in TFS. This will tell you who changed what files.
However what you're after is a little bit more than this - you want to know if the latest versions of any files have lines written by a particular user.
The Team Foundation Power Tools ship with a command-line version of annotate called "tfpt.exe annotate". This has a /noprompt option to direct the output to the console, but it only outputs the changeset id - not the user name.
You could also use the TFS VersionControl object model to write a tool that does exactly what you need.
If you install the TFS Power tools (at least for VS2005); it's called annotate.
It might be part of VS2008...
You can use TFS Analysis Cube to see generate a code churn report, which I believe is something you would like.
Annotate is now part of Visual Studio (I think it was introduced in VS 2010).
Docs
I'm writing an answer to an 8 year old question :). Its not really a full answer, but a suggestion to look into excel reports for TFS.
TFS2013 / 2015 on prem has something has an excel report that can be used to visualize Code Churn.
In VS open team explorer then select "Documents" then explode "Excel Reports". I believe Code Churn report has something like discussed. The report is made by some default project template so I think tfs2013 on prem just creates it.
Code Churn Excel Report VS2015
https://msdn.microsoft.com/en-us/library/dd695782.aspx
I had very similar requirement to get details of particular attribute in a file e.g. who added, when, related work items etc.; Following GitHub project is having implementation to get required details and required minimal changes to work with multiple files or project -
SonarQube SCM TFVC plugin
It requires analysis to be executed from Windows machines with the Team Foundation Server Object Model installed (download for TFS 2013).
This blog post is also having good explaination and sample application -
TFS SDK: Connecting to TFS 2010 & TFS 2012 Programmatically