Can/Will beta 2 SCC/WI data be preserved in the GA release
OK, we're interested in starting to use beta 2 for our next big project, however I need to know if the data we create using beta 2 can be preserved (or at least migrated) in the GA release Does the "go live" license apply to TFS too Dave
The "go live" license does not apply to TFS. I do not believe there are any commitments whatsoever regarding migrating beta 2 data to the production release.
I have to 2nd what Keith said - We'd love to jump all over it, but without some assurance that we can get our code to the GA version of TFS how can this be considered any better than the CTPs Even some level of migration (export/import, whatever) would give us what we need to decide if we should jump or not...
Am I crazy to think that for a company that has claimed to be dogfeeding their own products for now (what 2+ years) that database schema/data migration would have been part of the initial storyboards so that thise would be available to developers who were asked to use this To me it seems that this along with migration tools from vss to tfs would be something that would be in the intial storyboards and would be available by the time ms pushed tfs and said hey people you can now use this.
The VSTS team has been using TFS for source code control for nearly 9 months. In the beginning, we backed it up nightly to our old internal SCC system to make sure we didn't have a catastrophic failure (ie loss of source code). We've abandoned that process many months ago. Now we simply use TFS. We have never lost a line of code while dogfooding the servers. We use it for issue tracking as well. below i've included some stats from our server about 3 weeks ago...
In terms of migration, we migrate to a new build about once a month. Today this is still very painful and takes around a week. No, we obviously do not throw away history, files, etc. We custom build a migration tool/process for each migration.
With Beta 2 we have a small (about 10) set of customers that are in fact going live with the bits. For these customers, we committed to hand-holding the forward migration for each of them thru RTM. In terms of the stability of the server, we are confident that beta 2 is solid enough for people to start using themselves as we've been using it for many months. What we can't commit to is a broadly available forward migration path just yet. Within a few months we should have the churn out of the system enough to do that and at that point expect people to start their own pilot projects in earnest.
-Rick
Availability (over the past week)
The server was available 98.91% of the time.
Users
Users with assigned work items: 422 Version control users: 220
Work items
Work items: 21,262 CSS nodes: 1,693 Work item versions: 164,837 Attached files: 6,209 Queries: 1,606
Version control
Files/Folders: 64,766/8,762 LocalVersion: 3.35 million Total compressed file sizes: 667M Workspaces: 358 Shelvesets: 528 Checkins: 1396 Pending changes: 15579
Look, I've developed commercial software for many years on Microsoft SQL Platforms and I understand how difficult it can be to maintain data across schema changes - the main thing I want is an answer (or at least their intention) so I can make a decision
I can't imagine a product like this reaching public beta without some consideration of whether or not they can preserve the database for the GA release. I fully understand how CTPs by their nature are fair game to massive changes to schema/architecture/whatever but beta would seem to indicate a level of stability where my question could be answered.
Now, if their hedge is whether a database created in the April CTP of SQL 2005 can be migrated the GA release of SQL Server, then fine, at least tell me that.
They seem to want people to really start using this, but with something as core to a business as SCC, we'd like to know what we're signing up for. Dave
So - since you guys are "dogfooding" this does that mean that you throw away your SCC and WI data each time a new build is installed That's essentially what your telling us to do.
I'll have to think about this a little more before rolling it out. Dave
Dave, what is it that your needing Keeping the history on your source once RTM roles around or just making sure you don't lose your source code come RTM
I'm assuming it's the former. But being this really Beta1 (for VSTS) the team (I'm assuming) can't guarantee the SCC database schema won't change, therefore invalidating any prior SCC history.
If you could accept the fact that the history *may* be lost once RTM roles around, I'd be all for incorporating TFS into my projects now.
I'll add a few comments and hopefully it will help (but maybe not). As Rick said we've been using it interally for quite some time now. We refresh our "dogfood" server about every 3 months and each time we grow the number of teams using it and the number of features they are using. Every refresh before and including Dec 2004 we dumped all the data and started over. We could do this because we kept mirrors of everything in other systems.
Starting with our refresh in Mar 2005 we are now migrating data forward with every refresh. The one in March was very painful (the schema changed quite a lot) and took several weeks to get all of the kinks worked out. We will be doing another one in June where we hope to iron out the process a good deal more. Clearly we can't afford to go through this level of effort with a lot of people.
Unfortunately between this Beta and the next pre-release there will be quite a bit more schema churn - for example we have eliminated our AD/AM dependency because it has been proving to be too difficult for customers to work with and was not really matching the performance profile that we needed. This work has actually already been completed but due to the nature of Beta stabilization cycles (the bits you have now were branched months ago) it did not make it into the Beta release.
Our plan is that the first release where we will publicly support forward migration of data will be later this year. We will support migration of that data to RTM and beyond. Until then we will not be supporting forward data migration. Yes I know this is painful and it will limit the production use of the system. I hate that as much as you do.
For source code, clearly you can always get the source from the old version and add it back to the new one. Unfortunately you lose the history taking this path. For work items the problem is even harder because there's no easy way to perserve even that much. You could use the object model to export the data from the old version and then import it into the new. I'd be grateful if someone out there in the community would look at writing such a tool.
We're working hard to be able to support forward migration of all data and will get that capability to you as soon as we can.
We realize that this is an issue for customers and are investigating options for future community drops. Unfortunately, it is too late for us to address this issue for the Beta 2 drop.
Rick, thank you! That was the sort of information I was looking for. Of course, I would have loved to hear that MS is going to support a broader audience in migrating from B2. However, I do appreciate knowing what we can and can't expect.
For now, we should just plan on copying source from B2 to future drops. As for work items, I guess well just have to start over in future drops. That will probably limit how much we use the work item feature. Oh well. We're most interested in the version control aspects anyway.
I think it raises an interesting point/question. For a company that supposedly dogfoods everything of theirs you would think that developers would work on streamlining migration from one build to the next either through a natural process or with the process of a secondary tool. I know that in this case if i were dogfooding a source control management and maintenance i would have make sure that if the schema did change there would be tools to migrate the prior database to the new version, because I am dogfooding it and therefore everything that I do is extremely important. Sadly, I have yet to see a single instance where I could ever think that they "really" dogfooded something important, except maybe after it went RC
Hmm, how about source in the repository Will we be able to move that onto the final version of TF We would also like to start project development on B2 but we wouldn't if there wasn't a way to move our source onto the final version.
In general, do you think the state of TF is good enough for real project development purposes I don't expect a glitch free experience but it has to be good enough as to not trash our source on a regular basis. :-)
We haven't been dogfooding it for 2+ year - It's been about 8 months :) A converter from SourceSafe has been planned from the beginning as you suggest and is available in the Beta.
The issue of migrating from build to build has been on the radar for a long time - it's just that it's a tricky problem to solve while the schema is still so much in flux (and it was at the time we snapped the sources for the Beta). Our plan is to lock down the schema and the protocol in about 4 weeks and migration will become much more straigt forward at that time.
Today, every time we do a dogfood migration, there is several weeks of work to build the scripts to migrate from the old schema to the new schema. I very much understand that not supporting this is a pain for people and I'm very sorry about that. We will begin supporting this publicly as soon as we can.
Brian
Can/Will beta 2 SCC/WI data be preserved in the GA release
Can/Will beta 2 SCC/WI data be preserved in the GA release
Hades Pta
Buck
KentNguyen
Even some level of migration (export/import, whatever) would give us what we need to decide if we should jump or not...
Dave
gforbes
GypsyJazzMan
The VSTS team has been using TFS for source code control for nearly 9 months. In the beginning, we backed it up nightly to our old internal SCC system to make sure we didn't have a catastrophic failure (ie loss of source code). We've abandoned that process many months ago. Now we simply use TFS. We have never lost a line of code while dogfooding the servers. We use it for issue tracking as well. below i've included some stats from our server about 3 weeks ago...
In terms of migration, we migrate to a new build about once a month. Today this is still very painful and takes around a week. No, we obviously do not throw away history, files, etc. We custom build a migration tool/process for each migration.
With Beta 2 we have a small (about 10) set of customers that are in fact going live with the bits. For these customers, we committed to hand-holding the forward migration for each of them thru RTM. In terms of the stability of the server, we are confident that beta 2 is solid enough for people to start using themselves as we've been using it for many months. What we can't commit to is a broadly available forward migration path just yet. Within a few months we should have the churn out of the system enough to do that and at that point expect people to start their own pilot projects in earnest.
-Rick
Availability (over the past week)
The server was available 98.91% of the time.
Users
Users with assigned work items: 422
Version control users: 220
Work items
Work items: 21,262
CSS nodes: 1,693
Work item versions: 164,837
Attached files: 6,209
Queries: 1,606
Version control
Files/Folders: 64,766/8,762
LocalVersion: 3.35 million
Total compressed file sizes: 667M
Workspaces: 358
Shelvesets: 528
Checkins: 1396
Pending changes: 15579
Sudripta
I can't imagine a product like this reaching public beta without some consideration of whether or not they can preserve the database for the GA release. I fully understand how CTPs by their nature are fair game to massive changes to schema/architecture/whatever but beta would seem to indicate a level of stability where my question could be answered.
Now, if their hedge is whether a database created in the April CTP of SQL 2005 can be migrated the GA release of SQL Server, then fine, at least tell me that.
They seem to want people to really start using this, but with something as core to a business as SCC, we'd like to know what we're signing up for.
Dave
Romeu
I'll have to think about this a little more before rolling it out.
Dave
Jim Glass MSFT
I'm assuming it's the former. But being this really Beta1 (for VSTS) the team (I'm assuming) can't guarantee the SCC database schema won't change, therefore invalidating any prior SCC history.
If you could accept the fact that the history *may* be lost once RTM roles around, I'd be all for incorporating TFS into my projects now.
Dave Bost
blog: http://www.davebost.com/blog
BrandonHeidepriem
Starting with our refresh in Mar 2005 we are now migrating data forward with every refresh. The one in March was very painful (the schema changed quite a lot) and took several weeks to get all of the kinks worked out. We will be doing another one in June where we hope to iron out the process a good deal more. Clearly we can't afford to go through this level of effort with a lot of people.
Unfortunately between this Beta and the next pre-release there will be quite a bit more schema churn - for example we have eliminated our AD/AM dependency because it has been proving to be too difficult for customers to work with and was not really matching the performance profile that we needed. This work has actually already been completed but due to the nature of Beta stabilization cycles (the bits you have now were branched months ago) it did not make it into the Beta release.
Our plan is that the first release where we will publicly support forward migration of data will be later this year. We will support migration of that data to RTM and beyond. Until then we will not be supporting forward data migration. Yes I know this is painful and it will limit the production use of the system. I hate that as much as you do.
For source code, clearly you can always get the source from the old version and add it back to the new one. Unfortunately you lose the history taking this path. For work items the problem is even harder because there's no easy way to perserve even that much. You could use the object model to export the data from the old version and then import it into the new. I'd be grateful if someone out there in the community would look at writing such a tool.
We're working hard to be able to support forward migration of all data and will get that capability to you as soon as we can.
mangorind
We realize that this is an issue for customers and are investigating options for future community drops. Unfortunately, it is too late for us to address this issue for the Beta 2 drop.
Thanks,
Ling
Studying
For now, we should just plan on copying source from B2 to future drops. As for work items, I guess well just have to start over in future drops. That will probably limit how much we use the work item feature. Oh well. We're most interested in the version control aspects anyway.
g_politis
I know that in this case if i were dogfooding a source control management and maintenance i would have make sure that if the schema did change there would be tools to migrate the prior database to the new version, because I am dogfooding it and therefore everything that I do is extremely important.
Sadly, I have yet to see a single instance where I could ever think that they "really" dogfooded something important, except maybe after it went RC
RyanL
"They seem to want people to really start using this, but with something as core to a business as SCC, we'd like to know what we're signing up for."
Hear, hear!
jkisha
In general, do you think the state of TF is good enough for real project development purposes I don't expect a glitch free experience but it has to be good enough as to not trash our source on a regular basis. :-)
pmarreddy
The issue of migrating from build to build has been on the radar for a long time - it's just that it's a tricky problem to solve while the schema is still so much in flux (and it was at the time we snapped the sources for the Beta). Our plan is to lock down the schema and the protocol in about 4 weeks and migration will become much more straigt forward at that time.
Today, every time we do a dogfood migration, there is several weeks of work to build the scripts to migrate from the old schema to the new schema. I very much understand that not supporting this is a pain for people and I'm very sorry about that. We will begin supporting this publicly as soon as we can.
Brian