A branch has been deleted but tf get still gets files in the branch
As you can see below the Code-Iteration-1 folder has been deleted
C>tf dir "$/System" /folders /deleted
$/System:
$Code
$Code_CI_1
$Code-Iteration-1;X104
$Documentation
Code-Iteration-1 does not show in the Source Control explorer in VS2005
But it shows in tf dir:
C>tf dir "$/System" /folders /recursive
$/System:
$Code
$Code_CI_1
$Documentation
[text deleted for clarity]
$/System/Code-Iteration-1:
$CITSln
$Content
$ThirdParty
$Tools
$/System/Code-Iteration-1/CITSln:
[text deleted for clarity]
When i do a tf get /all I still get all the files in Code-Iteration-1
I feel that this must be a bug in Team System - somehow the database has become inconsistent.
Is there anything we can do to fix this problem. Is there some kind of database consistency tool that can be used to diagnose and fix such problems ?
The current situation is not a major problem at the moment, but it worries me to use an inconsistent version control database for an important project.
Some more background about how we came to this state:
The database was created using the Beta3 refresh version of TFS
A user tried to create a branch of the Code folder, calling the branch Code-Iteration-1. The user then changed his mind and tried to delete the branch again.
He then checked in both the branch and the delete as a single changeset. Maybe this caused the problem.
C>tf changeset 1028 /nopromptChangeset: 1028
User: XXXX
Date: den 4 april 2006 13:09:53
Comment:
trying to delete
Items:
branch, delete $/System/Code-Iteration-1;X104
branch $/System/Code-Iteration-1/CITSln
branch $/System/Code-Iteration-1/CITSln/AuthenticationModule
branch $/System/Code-Iteration-1/CITSln/CIT.PatientModule.Client.Test
branch $/System/Code-Iteration-1/CITSln/CIT.PatientModule.Client.Test/AuthoringTests.txt
We have now upgraded to TFS RTM, and we still have the problem.
[2738 byte] By [
stegus] at [2008-2-22]
I made the change in Tools -> Options -> Source Control -> VSTF. to view deleted items. Now the Code-Iteration-1 folder was shown as a deleted folder and all its chidlren was shown as normal children.
To fix the situation I tried to undelete the Code-Iteration-1 folder, and check in my pending changes.
This seemed to work well, I got no error messages, and everything now looks normal.
The next step was to try to delete the folder again.
I selected the folder, right clicked and selected delete.
I now get the following scary error message:
A database error occurred (SQL Error 2627)
Violation of PRIMARY KEY constraint PK_tbl_RevertTo Cannot insert duplicate key in object dbo.tbl_RevertTo
CMPLTAPP.TfsVersionControl..prc_PendDelete: Database Update Failure - Error 2627 executing INSERT statement for tbl_RevertTo
The statement has been terminated
I get the same error message when trying to pend a delete for any of the phantom children. Everything works as expected in other parts of the database.
As I suspected, something is inconsistent in the database.
What should I do to fix the problem ?
There are 3 aspects that should be improved in the SCE.
1- Project portals should support sub-project portals so that we can organize better our version tree. We have lots of projects and they are organized as groups. Inside these groups the projects are very similar with each other. For example, in my image, the projects created in branchteste1, like cvstest or jfdois, could have an independent project portal as an option. This could help to organize similar projects in project portal groups.
2- Tfsdeleteproject is great but there should be a destroy feature. Think about a medium-large enterprise that has 60 or 70 projects per year and most of them are not released. This means that these projects only have prototypes launched and eventually the project is dropped. If we want to destroy the project, we can’t.
3- Deleting brached projects can cause the organization caos described above. Most of our prototypes are branched projects. If in 70 possible projects per year we manage to get 30 projects running there will be 40 ghost projects in the database. This is a huge issue.
"Deleted" projects being completely hidden is more important than destroy. Companies I've worked in want nothing destroyed.
In larger companies, there'll be hundreds of projects and having obsolete areas still visible is going to lead to alot of confusion. Yes they can't do anything with them, but at larger workplaces things like naming conventions change and need to be implemented firmly across the board. Having junk projects show up will force DBA's to go in and try to destroy the old projects, which could be ugly.
Just my 2 cents having used many revision control systems. The lack of that could delay larger places from rolling over from VSS.
Regards,
Dave
