I want to migrate from star team 2005 to TFS 2010 with HISTORY. Is there any tool or any way where I can do it cost effectively. I know about Timely Migration tool, but it is too expensive.
There is no tool out there to do this. You are stuck with paying for Timely Migration or writing it yourself. Capturing history from StarTeam is extremely complex. The reason for this is because of what the view looks like historically. You can roll back the view to a point in time, and this alone works very well, but rolling back to every point in time where a change happened to the view is practically impossible to do using the API. This is because 1) not everything has an Audit record, so you can't use the audits, and 2) the audit records are purged, 3) there is a special feature to "play back" the history of the view to generate the listener events (requires MPX), but this will miss many events, 4) when items are shared, configured, branched, etc., these do not generate any audits in the project, 5) even if they did, getting every single change requires iterating through the view history down to the second to get all of the changes by analyzing the differences. So that means if your project has been active for a month and each time you analyze the two view configurations to diff them it takes 5 seconds, then actually migrating your project would take 5 months, and in the meantime it would be locked down.
So the next way to do this would be to establish "baselines" to compare. Using build labels is a good starting point if you have nightly or continuous builds in your project, or even just certain builds that were QA certified. This way you can use these baselines as points for diff/compare and then bring in the history that way. While this isn't as granular as a full history, it is by definition getting the most important differences to migrate over.
However, keep in mind that even doing it this way does not maintain the links between branch/merge points across the different branches/views. The only way to do this would be to go directly into the StarTeam database to get this information.
I went through all of these steps to try and write my own suite of tools to migrate from StarTeam to Subversion. It was fun and interesting and imperfect but had some promise, but ultimately never finished it. Part of the reason was because the time involved would have been far more than the value I got from it.
Which brings you inevitably to the most important question: what is the business value of maintaining full history? After going through this many times with project teams as a StarTeam administrator, more than 90% of the time it was readily apparent that the better approach is a cut-over. Make a time where you can begin working on new work in the new system and freeze work in the old system. It usually can be done with very little down time for the project team. You can even start by bringing over a history of Production releases to create a rough timeline in the new system. Use your existing comparison tools, either in TFS or BeyondCompare or elsewhere, to reproduce each state of your project source code, doc, etc. and reconcile it with your TFS project by checking in or deleting files as needed, and labeling your TFS project for each build you bring over. Line up all your TFS builds, work items, users, roles, etc, and make sure everything is ready. Then at time of cut-over, take the latest development snapshot from StarTeam over and do one more update to your TFS project. Lock your Starteam users out of the project (for checkins anyway), and begin working in TFS. Your TFS project will have a rough history of the most significant baselines and you will be able to keep your StarTeam repository open to users in case more history is needed.
One other thing to consider is how to create a permanent archive of your project. If your repository is small enough it is doable, but gets more time intensive the larger your project is. First, copy your entire database and vault to a separate instance and get that copy up and running. Then delete all other projects EXCEPT the projects you want to archive off. Run an online purge and make sure to run it to completion. You may need to restart your server and purge several times. When you are done, your entire repository should contain only the files and database records that are needed by your project. At this point you can back up your database and vault and keep them indefinitely. This reduces the size of your existing StarTeam repository.
Haven't used StarTeam in over 3 years but that was a fun ride back in time. Hope you found it useful.
Related
I've been given the dubious hack of a task to stop tracking all "TFS stuff" from about a month back to the time it first started. Why? Because it's currently a behemoth. Over half a million files and close to six digits of changesets across loads of inter/cross-connected branches for a "legacy" code repository where no one cares about the "old stuff"'s history or access to old files, but they need what's currently in the repo to stay there.
The problem is, at its current state it is making interacting with TFS a huge pain. The few devs who still touch this code base often have IDE crashes when trying to do simple things like, access the source control explorer, checkin, etc... really basic things have become sketchy from TFS bloat. If I want to merge a single changeset from one active branch to another, I get lag with the lists loading for 5-10 minutes instead of a few seconds.
While researching, I ran across this old question. It seems like it may be what I need, but I'd hate to find out the hard way that I used the commands incorrectly and have to re-load the snapshot for our TFS server, as this repo is worked on in multiple timezones.
How do I reset/purge history, shelvesets, work items, and anything else before say, C20,0000, meaning, I don't care about anything before C20,000, but I want all the files that exist at the time of C20,000, even if one of those files was part of say, C12, but is still in the repo and unchanged.
If the linked-to answer provides the answer I need, but not the clarity, I'm fine closing this as a dupe so long as the other answer gets updated with clarification.
I'd like to do something along the lines of this pseudo-code:
tfs nuke $collection/$ProjectName beforeChangeset:C20000 /keepCurrentFiles
I'm guessing that will require multiple commands for things like files and shelvesets, but that's the gist of what I'm trying to accomplish.
I want to use a versioning system to back up and track my changes but I'm too lazy to check out/check in, merge, commit, etc. I don't want to branch, fork or anything else. I just want to be able to see what files have changes and what my Main() looked like last week.
So I'm looking for an application that will simply take my Visual Studio projects folder and back it up in such a way that all prior versions of the files are preserved so I can not only have a backup, but I can easily see how the file looked at some point in the past without me having to explicitly put it in a repository, update/commit/merge/etc.
Basically what I'm looking for is dropbox's functionality but on my local machine and without the 30 day limitation of prior versions.
Does such an application exist?
As AlexC stated, I highly doubt that the little bit of work you save by not using a version control system explicitly is worth the drawbacks, but anyway:
Simplest idea: Just write a wrapper script that checks out the HEAD of your repository, starts Visual Studio and commits everything to version control after you close it.
Alternatively, just trigger commits every hour. With most VCSes, non-modified files won't show up in the listing of modified files.
Currently I am working on a project that uses TFS as source control. I am in the middle of implementing a piece of functionality, but am blocked by work that needs to be done by outside resources. Since the functionality is not fully complete, I can't check in the changes without breaking the build. So instead of waiting a couple days while the blocking work is finished, I want to work on some defects.
To do this work in isolation from my other changes, I am working the defects in a second workspace I just created.
After using a second workspace to isolate my changes, a coworker asked me why I didn't just shelve my changes. After doing some reading on shelving, it looks like this is preferred solution to situations like mine. My question is what situations, if any, would you create multiple workspaces and what situations should you use shelving? There are some posts about shelving, but I don't see very much on the subject of workspaces.
By the way, I got the idea for creating a second workspace here.
A new branch would probably be the best way to go. But, to answer your question, one of the key differences between shelving and just using a differnet workspace is that when you shelve, you push your code back to TFS, so it is backed up. Whatever is in your workspace is just what you have on your machine -- if you lose it, it's gone.
We use branching a lot in my shop, and as a result, I haven't seen many uses for shelving.
However, I have found one case where it has been very useful to me:
I often bounce between 2 different development machines (one at the office, one at home, connected via VPN). If I am working on something, and I want to transfer it from home to work, or vice-versa, I often use shelving. I can shelve it from one machine and un-shelve it from the other. I do this when I am in the middle of a change, and checking in would break the build or otherwise interrupt other developers.
You are talking about two completely different concepts here. When you shelve code, you are saving it to TFS, but not checking it in to any particular branch. Creating a different workspace just sets up a new local folder on your development machines and saves the files in your branch there. When you do a check-in, you still could have conflicts.
Why not create a new branch of your code. You can work on that branch and check in without stepping on anyone else's changes, because you are checking in to your own branch of the code. Then, when you have completed your changes, and others have completed their's on the main branch, you can merge your changes into the main branch.
Shelving is the ideal option. Shelving allows you to make changes en masse in TFS outside the regular build, and retrieve them later by name. Multiple workspaces is not a solution for what you're doing. Multiple workspaces are good if you're maintaining different versions of a product and need to work on them, e.g. let's say you have a 4.0 and a 5.0 product and need to apply a security fix to both versions. Shelving is great when you want to make changes but not commit them immediately.
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.
We currently have a fat SourceSafe DB with ten years of code in it. We're looking for an easy and stable way to import all of this in to a new Clearcase/Jazz environment.
What is the best best method of doing this and are there any tools out there to do this automagically?
I know this doesn't answer your question directly, but we had a similar problem several years ago when we moved from VSS to Perforce. We looked at the ways in which we could migrate the histories for all the files, but any solution we found had problems and would have taken a long time to execute.
In the end we simply decided to import the current version of the code into Perforce as the baseline and leave the old history in VSS. In the early days we did refer back to VSS occasionally, but after a few months we didn't need to.
If there's a problem with a file you only need the last couple of revisions to be able to see what's changed and why. So if the file changes fairly frequently you'll soon build up a useful history in the new repository. If the file doesn't change then by definition it's stable an you don't need the history.
If you back up the old repository you can always go back to it if you really need to to dig out the hold history.
In theory, clearexport_ssafe is the right tool:
The clearexport_ssafe utility reads the files and sub-projects in your Microsoft® Visual SourceSafe current project and generates a data file, which clearimport uses to create equivalent VOB elements.
By default clearexport_ssafe exports the files and subprojects in the Visual SourceSafe current project, but it does not export any files contained in subprojects. To export all files in all subprojects, specify the –r option.
In practice, the migrations I made (not from VSS though) involved the import of a few recent labels, and then the HEAD, into ClearCase.
That means the main tool I use for any import (from any other VCS) is clearfsimport.
You may loose some meta-data (like the author of a version, and labels), but at least it is source-agnostic, and since your massive import only concern an handfull of labels from the source, you end up quickly with an operational VOB.
From IBM's web site:
http://www-01.ibm.com/support/docview.wss?ratlid=cctocbody&rs=984&uid=swg21222507
and this:
http://www.cmcrossroads.com/component/option,com_fireboard/func,view/id,63051/catid,31/Itemid,593/
However, ChrisF's answer is the same that I would suggest.
The effort involved generally is not worth it given the "benefit" of migrating the history.
I would just take snapshots of the current "tips" of the branches and put those under your new version control system.
I went through this exercise at least 3 times in my career. One conversion to Perforce and two to SVN.
I think I recall that we did some partial history imports, but then just dropped it all as the information we needed was in some other form. The actual repository history of changes just wasn't important enough to go through the pain. We did keep the database around for a year or so in case anyone wanted to look. I don't recall anyone complaining about it.
(I'm also curious why anyone would choose ClearCase over the rest of the ones out there - my guess is for integration with other Rational/IBM stuff)
EDIT
I would ask ClearCase/IBM. They'll have the best up to date information.
I actually lived through a VSS to Clear Case conversion. Rational had a conversion tool that we ran. It took FOREVER (2-3 days, but see below) to complete on our VSS database of maybe 2 years (maybe it was 3 years, but not close to your 10 years). But it worked far as I recall. It maintained the history and labels.
The slowness problem was likely due to a flaky RAID controller in our new source control server. The imports worked fine, but Clear Case would detect corruptions in it's data after a few days of working (often after a label). After several re-imports, firmware updates, and a new server it all worked out.
I'd still plan to give the import a weekend to run. Try to get someone who can remote in occasionally to check it's progress.
On a side note, I've also done VSS conversions to Perforce and TFS. In general, I suggest giving the import tools a try. If they work, great. If they give you grief, just do what everyone else answering is suggesting: just start over by adding all the files as new.
I'd take the most significant labels and import them into ClearCase by 'clearfsimport'.