Migration Results Differ Dramatically

Mar 10, 2009 at 5:42 PM
Does anyone have any ideas why the following may happen and what can be done to prevent this in the future?

I successfully migrated source (no WIT) from one TFS server to another in 1 hr.  When I tried to migrate the same source from one project to another on the same server it took about 9 times longer. 
Any suggestions on why this would happen is appreciated.

No one was able to change anything during the migration either on the from or to side, permissions were identical.


Developer
Mar 10, 2009 at 5:51 PM
Good to know that the migration tools work for you. Regarding the performance issue. Can you send us the log file for further investigation.

Here is one possibilty that may cause the performance degradation of your 2nd migration (without the log file, this is just my guess) - Your 2nd server has more old(existing) changesets than the 1st source server. The current migration tool spend time to examine all changesets to see whether they are mapped or not. This can take a lot of time if you have a lot of existing changesets on your source system.

Thanks,
Pei
Mar 10, 2009 at 6:30 PM

Hello Gupei,  the log files are too big to send.  When you say it examines all changesets, do you mean all (entire server) Team Project changesets or just the Team Project used for the migration?

I will try and clean up the log files to send you a sampling of what I am seeing.

Any other ideas you might have would be great…J

From: gupei [mailto:notifications@codeplex.com]
Sent: Tuesday, March 10, 2009 12:52 PM
To: Bates, Kim (West)
Subject: Re: Migration Results Differ Dramatically [tfstotfsmigration:49757]

From: gupei

Good to know that the migration tools work for you. Regarding the performance issue. Can you send us the log file for further investigation.

Here is one possibilty that may cause the performance degradation of your 2nd migration (without the log file, this is just my guess) - Your 2nd server has more old(existing) changesets than the 1st source server. The current migration tool spend time to examine all changesets to see whether they are mapped or not. This can take a lot of time if you have a lot of existing changesets on your source system.

Thanks,
Pei

Read the full discussion online.

To add a post to this discussion, reply to this email (tfstotfsmigration@discussions.codeplex.com)

To start a new discussion for this project, email tfstotfsmigration@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Mar 10, 2009 at 6:42 PM
Yes, I mean the entire server. But it will start with the 1st changeset under your mapped paths, not changeset 1 across the entire server. However, if you create your mapped path very early, say, changeset 2 and make real changes at changeset 1000, the migration tool will analyze all 999 changesets.

We have optimized the analysis performance for the next release. I'll let you know when that one is available.

Thanks,
Pei
Mar 10, 2009 at 6:46 PM

Gupei, Thanks for the info.  Will this be the same process everytime? i.e. I have another migration planned for tomorrow that should take 4 min (at least it did on the server to server migration)?

Thanks!!

From: gupei [mailto:notifications@codeplex.com]
Sent: Tuesday, March 10, 2009 1:43 PM
To: Bates, Kim (West)
Subject: Re: Migration Results Differ Dramatically [tfstotfsmigration:49757]

From: gupei

Yes, I mean the entire server. But it will start with the 1st changeset under your mapped paths, not changeset 1 across the entire server. However, if you create your mapped path very early, say, changeset 2 and make real changes at changeset 1000, the migration tool will analyze all 999 changesets.

We have optimized the analysis performance for the next release. I'll let you know when that one is available.

Thanks,
Pei

Read the full discussion online.

To add a post to this discussion, reply to this email (tfstotfsmigration@discussions.codeplex.com)

To start a new discussion for this project, email tfstotfsmigration@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Mar 10, 2009 at 6:51 PM
The migration tool keeps a high water mark for each session. That is the last changeset migrated. So if you resume that session, it will start from that changeset.

However, if you need to change the mapping and start a new session. The migration tool will restart the analyze process from beginning.

Thanks,
Pei
Mar 10, 2009 at 6:54 PM

Ok, one more question.  Why doesn’t it do this when you migrate from server to server?  I am wondering if I should migrate from prod to qa and then qa back to prod?

Thoughts?

From: gupei [mailto:notifications@codeplex.com]
Sent: Tuesday, March 10, 2009 1:52 PM
To: Bates, Kim (West)
Subject: Re: Migration Results Differ Dramatically [tfstotfsmigration:49757]

From: gupei

The migration tool keeps a high water mark for each session. That is the last changeset migrated. So if you resume that session, it will start from that changeset.

However, if you need to change the mapping and start a new session. The migration tool will restart the analyze process from beginning.

Thanks,
Pei

Read the full discussion online.

To add a post to this discussion, reply to this email (tfstotfsmigration@discussions.codeplex.com)

To start a new discussion for this project, email tfstotfsmigration@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Mar 10, 2009 at 6:57 PM
It do this in any situations. That's my guess - your 1st migration is from a server with less (much less?) overall changesets than the 2nd one.
Mar 10, 2009 at 8:18 PM
I work with Kim. I've read your discussion and it doesn't make sense that it would take longer when the source server for the migration was the same for both migrations. It was the destination server that was different. The first migration from "TFS Server A, project Cass" to "TFS Server B, project Ottertail" took 1 hour 40 minutes (source and destination were DIFFERENT TFS servers). The second migration from "TFS Server A, project Cass" (exactly the same source with the same changesets) to "TFS Server A, project Ottertail" has taken over 7 hours so far (source and destination are the SAME TFS server).  Does something different happen when the migration from source path to destination path is on the same TFS server?
Thanks.
Jane
Developer
Mar 10, 2009 at 8:21 PM
If that is not the case. We need the log file (both migrations) for comparison and further investigation.