Has anyone got any great ideas or experience around easily producing Branch Diagrams against TFS?
TFS 2008 does not include this functionality, so you'll have to resort to a plug-in/add-on. I haven't found any mature projects that produce branch or version diagrams, though many allow browsing of branch/version trees.
Team Foundation Sidekicks has a History Sidekick that includes version tree browsing
Vertigo plans to include version tree browsing for individual files, as well as branches, but is still in alpha.
Very similar questions already answered:
View TFS checkin history through merges?
TFS Branch/Merge meets History View
If you don't mind setting up a 2nd server just for playing with branch visualization, TFS 2010 Beta 1 is going to render by far the best diagrams.
Related
I have a requirement of moving Team projects between two team project collections in TFS 2015. Also need the History & Label to be moved to the new collection.
I am aware there is no direct way of moving the project between collection along with history & label.
Can someone suggest a better way to handle it?
Thanks in Advance,
Dinesh
There is already a UserVoice for this request, and this feature is under plan:
We are committed to allow you to move team projects between
collections, although it’s currently not in scope for the 2016
calendar year. We’ll provide an updated timeline as we get closer to
2017.
An alternative, you can try with 3rd tools to move team projects, such as TFS Integration Tools, OpsHub. Please read the limitations before using the tools.
We have a situation where at a point in our project's life, we needed to split off work item tracking and source control into 2 separate TFS projects, with the work items being in a VS Team Services project, and the source on-prem in TFS 2013.
The reason at the time being, we needed to grant access for our stakeholders to the product backlog, without them being on the corporate network where TFS is hosted. At the time there was concerns about security of the source code, hence the whole project was not lifted and shifted, just the backlog.
Now we're realizing some of the security concerns were not warranted, and we are missing out on the integration of ALM provided by a single project having both responsibilities, and would like to merge our source control out into the cloud-based VSTS project.
The problem is, the migration tools are overwriting the Work Items in VSTS. Is there some way we could merge, preserving that data, or any alternative to merge these two things together somehow?
I think you're looking at the Team Foundation Server Integration Tools here if you want to migrate source code history. Bear in mind that it's not going to be perfect (data time stamps will not be the same etc.).
If you can get away with it then just stick the latest code in VSTS and consider the on-prem server your archive should you need to go back. That doesn't tend to be too popular so you'll be wrestling with the integration tools. It's not the most friendly thing to use but mostly it will get the job done.
When you configure your session, you will want to choose Team Foundation Server\VersionControl.xml for your configuration. Then select a One-way-migration between your on-prem and VSTS.
You'll need to install VS 2012 or at least the Team Explorer.
Edit Coincidentally I had to do this myself so I blogged about the process here
I want to do daily migration of TFS changes to a ClearCase system. I was going to try out TFS Integration tools but I can't get any of the toolset pieces to work. What are the requirements to run this app? I have VS 2010, TFS 2010 and Sharepoint 2010 installed. The assemblies it's trying to load don't seem to be present in VS2010 and I don't if it requires VS 2008 or not. Anyone ever had this running? I'm migrating from TFS to CC. Not the other way around.
Update:
I've been using this tool to sync TFS 2010 changes back into a UCM ClearCase implementation at the client. It has been going poorly. The tool should be clearly marked as Beta or even Alpha. A peek into the code reveal around 100 TODO's and "This needs to be fixed". I have spent a good deal of time trying to iron out some of the issues and have made progress. My suggestion is before using this tool on mission critical projects, spend at least 3-4 weeks evaluating it in your environment. When it works, it works pretty well with moving changes.
I don't know much about how to access TFS2010 elements, besides "check an individual project for pre & postbuild steps either by loading the project in visual studio or manually reading the project file".
If you need Sharepoint assembly, this technote describes the requirements.
And I don't think an automatic import utility exists (from TFS2010 to ClearCase 7.1.x), as this technote mentions:
Change request (RFE) RATLC01005874 had been submitted requesting a conversion utility to export source code from Microsoft Team Foundation Version Control (TFVC) to ClearCase;
however, the decision was made by Product Management to exclude the requested feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
The right approach is to manage to list the content of relevant labels for a given scope, and make a clearfsimport into a ClearCase view, with a full label applied right after it.
You don't need TFS (server), VS or SharePoint installed. You will need a SQL server for the core platform. Then you will need the various assemblies for TFS, which you can get by installing the Team Explorer component (it's on the TFS install media).
We decided to go with the TFS Integration Platform. It allows us to sync TFS work items back into ClearCase when ever we want. It provides the level of integration we needed to keep the traceability. The TFS to CC integration is bleeding edge, but it works enough for what we need. (Syncing work items and user check ins.)
Two questions really..
Does anyone know of a cheap solution for converting a CVS repository to TFS?
I think we may have to convert to SVN then convert to TFS. Has anyone had experience doing so?
Please, no comments on why we are using TFS.
The TFS Integration Platform on Codeplex is written to support integration into and out of TFS. Though it is primarily written for a TFS to TFS scenario, the code is available for you to tweak as necessary.
A few years ago, we used the original version of this (called the TFS to TFS Migration Tool) to facilitate our migration from Borland StarTeam to TFS. It worked really well.
The key thing you're going to need to decide is whether or not you want to bring over history. That's where things can get a bit more difficult, as you will need to rebuild the history from the beginning of the CVS repository. This means reading the first revision of all the files, checking them into TFS with appropriate comments, then getting the second changeset, checking in those files, ad infinitum.
Our team would like to move from the Visual SourceSafe (VSS) to the Team Foundation Server (TFS). I know that the TFS is much more than just a version control system, but for the first time I would like to use it this way.
Currently our projects are organized within the single solution that consists of the shared part (common library) and many customer projects.
Is there some kind of migration guide that would describe such a challenge? Or TFS enforces its own usage scenarios (versioning of projects, releases, etc.)?
TFS certainly has much more potential than just as a source repository, but it's quite understandable why you would want to migrate source control first.
The migration utility of choice is generally VSSConverter.exe which allows you to map VSS paths to Team Project source control paths and is pretty well documented in this walkthrough here.
There's another tool (TFS Migration and Synchronization Toolkit) available over on CodePlex, but when I compared the two, I determined that VSSConverter has been more widely used and I think is generally accepted as being the tool of choice for VSS migrations.
It seems there are a few more answers on this thread here also.
Now, the question I think you are really asking is more about guidance on creating Team Projects and structuring?
This is a little harder to answer without knowing more about your specific circumstance. Patterns and Practices published a book on CodePlex called the TFS Guide which might help - it describes amongst many things, a suggested Team Project source control structure. It might help in giving you some guidance around how to migrate and/or remap your solution structure.
Regards to versioning and branching, check out this site here on branching guidance - it's not a bad overview of some common branching/release management techniques using TFS.
If you get through all that reading, you'll really be on top of most of the essential TFS groundwork!
(Feel free to downvote me but...) If you're after better source control then TFS is IMHO overkill. I recommend you look into Subversion. VisualSVN is a superb ($49) plug-in to Visual Studio that works seamlessly alongside arguably the best SVN client TortoiseSVN. In addition they provide a free, easy to set up, Windows package of the Subversion server-side stuff called VisualSVN Server.
To learn all about the Subversion way of working there's the great Red Bean book.
(Not affiliated with VisualSVN, just a Subversion fanboy)
TFS and VSS are radically different beasts.
That said, the major problems with moving from VSS to TFS is generally in the developer's mind.
Check out the following blogs:
TFS from a VSS User's perspective:
http://blogs.msdn.com/robcaron/archive/2006/10/29/901115.aspx
And of course, the original
http://sstjean.blogspot.com/2006/10/document-from-vss-to-tfs-introduction.html
When we switched from Sourcesafe to TFS2005 the biggest hurdle were Sourcesafe's shared files, the "Get latest on checkout" approach and the branch/merge "support" in Sourcesafe. Everybody feared branching and merging in Sourcesafe and it took some time convincing all colleagues that it is not that bad with TFS.
We decided to not migrate files from Sourcesafe. We used TFS2005 for a new project and kept the old stuff in Sourcesafe. We didn't want to keep the project and folder structure which had grown over the years and was rather unorganized.
The old stuff is history now and we do all development work with TFS2008.