VSS to TFS2010 lose history of shared files

Question

Hello

We are hoping to move our source code control from VSS6 to TFS2010.  I am doing some tests prior to migration.  We use the file sharing option of VSS6 extensively and  understand that TFS2010 does not support file sharing.  We have reorganized our VSS6 projects in preparation for migration.  Our goal with reorganization is to continue to allow the same source code file to be used in multiple projects.  This is very important to us.

I followed the steps in the article: http://msdn.microsoft.com/en-us/library/ms253060.aspx when migrating. I am using the vssconverter shipped with TFS2010. 

The issue we have is that the file history of shared files is not complete; it only includes changes made to files after the project was created (basically the last share point).  In VSS6 the full history of the file is available after sharing from all projects. The projects we are trying to migrate were created recently (4/5/12) and all files in these projects are shared from existing VSS projects.  When these projects are migrated we lose all the history prior to the project creation date.

The converter log files and vssmigrationreport.xml do not show any errors.   I have enabled verbose logging and can see the history of each file in the migration log file but it does not get to TFS.

The project map below shows migration settings for one project;  "1304" project was created in VSS on 4/5/12..

<ProjectMap>

<Project Source="$/cpu2/gage/fortran/1304" Destination="$/cpu2-c/test/fortran/1304-3"></Project>
</ProjectMap>
 

I know a similar question was asked in this forum in October of 2010 but there was no reply.  I'm hoping someone can help me with this question.  Yes, it is Fortran code that we are migrating ;-)

Thanks in advance.

Carol

Answer 1

Hello Carol,

Based on your description, it seems that you lose all the history prior to the project creation date, what is the project you are referring to? Do you mean the projects in the VSS? And what is the relationship between the project and the shared file?

In addition, I am trying to involve someone familiar with this topic to further look at this issue.

Thanks.

---

Vicky Song [MSFT]
MSDN Community Support | Feedback to us

Answer 2

Hi Vicky

Correct; I lose all history prior to the VSS project creation date.  The VSS project contains the shared files.  The history of the shared files pre-dates the creation of the VSS project.

I called MS Support regarding this issue.  My understanding is that the TFS database architecture does not support/allow any file history information that pre-dates the project creation date.  MS support has been very helpful and has given me a work around option to pursue.  I will post again after I try the work around.

Thanks

Carol

Answer 3

Hi Carol:

This is the design behavior of the VSSconverter.  This is an excellent reference: http://msdn.microsoft.com/en-us/library/ms253060.aspx

"Team Foundation version control does not support sharing. Shared files in your Visual SourceSafe database are migrated to Team Foundation version control by copying the version of the file that existed when it was shared and putting the copy in the destination folder. Thereafter, each changeset is replicated in both copies of the file."

In TFS, we base source control off of the folder date. If you share a file in VSS, you could have a file in a new folder where the date of the file precedes the date of the creation of the folder.  For example, the file history might go back to 01-02-2012 and the create date of the folder could be 03-10-2012.  In VSS this is not a problem; it was designed for file sharing.  However, this would pose a problem in TFS since we assume the folder is going to have the same date or an earlier date than the files it contains.

While verbose logging in the VSSconverter may list  entire history of the shared file, this information is not converted  to the file. 

Again, this behavior is by design.  There are no good workarounds.  Here are some ideas that might help:

You could try converting the original project (call it ProjectA) into ProjectB in TFS.  Then convert ProjectB in VSS (the one with the shared files) into ProjectB in TFS.  Depending on how many overlapping files you have between the two projects, this might help or you might end up overwriting files.

You could go to the original VSs folder- the “shared from” folder.  Then delete but do not destroy all the files in the source folder.  You can run the VSSconverter and move over only one file.  After the VSSconverter runs, you can go back and undelete the next file and delete the one you just moved.   This method gives you the total history of the file, but you are getting it from the non-shared copy of the file.

Have a great day!

---

Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.

Answer 4

Hi Trevor

Thank you for your reply.  I do realize that TFS does not support file sharing.  I did not understand why we were losing the history on migrated files but now understand that this is related to TFS not allowing file history dates to pre-date project creation date.  I had seen the discussion in the msdn article that you referenced regarding history issues with "moved" projects but did not make the connection to history issues with shared files.  Now I understand.

I know this is not the place to argue the benefits of VSS style file sharing but I will say that for my company the benefits outweigh the costs so we it extensively in VSS. For example, we have 10 projects where 90% of the files are the same (forms, general business rules, classes).  Our approach is to share these files between the 10 projects so that changes propagate to all projects. As part of our planned migration to TFS we reorganized our source code and source projects (pre-migration) in order to simulate file sharing with TFS.  Basically, the 90% of the files that were common to all projects were shared into a new VSS project and we migrated this new project to TFS. We also created 10 other VSS projects,  each with the unique 10% for the given project (again this was done using VSS sharing).  We shared the files because we thought this would allow the files in the reorganized projects to carry their history during migration to TFS.  I now understand why the history is lost so I am using a variation of one of your workarounds to accomplish our goal.

I am starting with an older base-line project from which most of files (90%) were shared from.  I delete the ~10% of the files that are unique to this VSS project (not shared with the other 9 projects).   Then I share a few newer files to this VSS project.  Once I have this VSS project populated with the shared files I migrate this project to TFS and all history is retained.  Then I deal with the files that are unique to each project.  I delete 90% of the files from each of the 10 projects leaving me with the 10% that are unique to each of these projects.  Then migrate these complete with file history... 

In the end my TFS project structure looks something like:
$/groupa/shared-90
$/groupa/project1
$/groupa/project2
:
.
$/groupa/project9
$/groupa/project10

I use the TFS recursive mapping option for the top level project ("groupa"). I edited the source code project files (.VBP and .DSP) to use a relative path when referencing the "shared" files.  This works as hoped when building projects in Visual Studio 6 and the MSSCCI allows a transparent connection to TFS from VS6.  MSSCCI  is very nice!

This is not a perfect "sharing" solution but it will work for us.  I think it may be similar to the file linking option that is available in Visual Studio 2010.  I do wish MS would add support for file sharing to a future TFS release.

By the way, I was not able to migrate more than one VSS source project into the same TFS project as I think you are suggesting.  I got error TF60099 when I attempted this.  Perhaps I was missing your point or had incorrect syntax in the migration XML file...

Thanks to you, and Lee from MS support, for your help. 

Carol

Answer 5

Carol,

Since you've opened a support case with us (Lee), I'll go ahead and let you guys work it out. If you'd be so kind as to return here and post your final outcome for the benefit of the community, that would be much appreciated.

---

Trevor Hancock (Microsoft)
Please remember to "Mark As Answer" the replies that help.

Answer 6

Hi Trevor

The work around discussed in my last post (April 19 6:15) worked for me.  Hope this information helps someone else out.

Thanks

Carol