We are going to be migrating an existing BizTalk codebase into TFS 2015 update 2. We would like to use GIT rather than TFVC for version control.
I have a problem getting my head around the repo to project relationship. I would like to run independent TFS projects for managing discrete pieces of work that align with "projects" as run by the business. Instinct tells me that I should create a branch for such projects but each TFS project seems to need its own repo?
If I stick with a single (BizTalk) TFS project, I will be able to create a branch for each business project but the work items will all be mixed together. This would make helpful reporting tools such as the burndown chart useless.
I guess the other option is to run multiple TFS projects each with their own repo and then manually merges between the repos? Maybe have a "Main" project and use its repo as the main branch of the project repos?
How are people managing this problem?
First note that inside a Team Project you can create several Git repositories.
Also, remember that Git branches have repository scope, it is not a directory like in TFVC (which it is not like Git at all :-) ).
Then if you want to migrate to Git, you need to modularize your projects. Once you have a modular code base, for each module you should create a Git repository. From each repository you should be able to build and publish a Nuget package. Then resolve inter module dependencies by resolving dependencies by means of Nuget package.
No need to merge anything from repo to repo or from module to module :-) You only need to merge from branch to branch inside the same repository.
The better way is that you can create multiple repositories in GIT Team Project.
Regarding work items, you may create multiple teams and areas, then put work items in different areas and change area per to requirements (the teams can have the same area).
There is a blog that may benefit you: Many Git Repositories, but one Team Project to rule them all
Related
I am looking for an alternative to branching in TFS with the goal of allowing multiple developers to continually integrate into a single changeset that is not in branch (aka a shelveset).
I know that a single user can update their own shelveset, and other users can pull that shelveset - but is it possible to allow several users to modify the same shelveset?
I understand that branching is preferred but I would still like to know if it is possible, maybe by using some sort of TFS powertool or modification.
No this is not possible. A shelveset is owned by a single user. it's also not recommended, as the shelveset is only a single snapshot of the change.
If you'd like something like this, you could consider git tf to create a local git repository which can be synced between two developers. Once they're finished one of the developers can push the change(s) back into TFS.
Moving from TFVC to Git has become easier with the release of TFS 2015u1:
Team Services | TFS 2015
In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project created with Team Foundation Version Control (TFVC). You can also add a TFVC repo to a team project created with Git. This allows you to adopt a new version control system while preserving all the data in your team project.
As to ways to persuade people to move, that's a hard question. You'd first need to understand what is holding them back, explain the, what advantages Git brings, what disadvantages you see in the current setup. You will probably need to hand-hold or train them so they get comfortable with Git. Using git-tf for a while may give them more confidence to make the move.
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.
At my work, we have a number of separate TFS projects that are combined together to form our Visual Studio solutions. These separate TFS projects are maintained so that we can reuse code across multiple solutions. Admittedly, this was a bad idea, as now when we have to branch we must branch each TFS project individually (we even wrote an app to do this). We end up with a project structure that looks like this:
$/Production/[superproject]/MAIN
$/Production/[superproject]/dev/[branch]
$/Production/[dependency1]/MAIN
$/Production/[dependency1]/dev/[branch/
where [superproject] requires [dependency1] within the solution. We end up mapping all these projects to the same workspace.
I would like to use Git-TFS in order to use Git in my day-to-day development. So far, the best way I have found to do this is to have a "master" git repo with a submodule for each TFS project. This way I can branch, diff, etc by using git submodule foreach.
Unfortunately, our policy regarding checkins is to have one changeset for a task, even if the changeset spans multiple TFS projects. This is fine if all my changes are constrained to one TFS project (i.e. one git submodule), but when I have changes across multiple submodules for one task then I don't know what to do. My current plan is to shelve each individualy using git submodule foreach 'git-tfs shelve mytask_$name' and then pull each into my TFS workspace, checking in from there. That only works for whatever TFS branches I have already mapped, which defeats half the purpose of using Git in the first place.
Has anyone encountered a similar problem? Are there any solutions already out there, perhaps using the TFS command line & a script? If not, I suppose I will spend some time creating a pull request for git-tfs. I am open to using Git-TF if the problem is solved there.
Thank you all in advance.
I think there is an effort in this way here : https://github.com/git-tfs/git-tfs/pull/350
you could have a look and contribute ;)
I'm the TFS admin at my company. In the past, I have recommended a linear branching strategy for small teams that are also new to TFS. Start in Dev > Dev merge up to Test > Test merge up to Prod.
This works well with solutions whose projects are subdirectories of the solution. What about projects that are dispersed throughout source control?
Can I create a single branch that that can manage projects dispersed in various locations in source control?
E.G.
\$TFS\Dev\Project1
\$TFS\Dev\SomeFolder\Project2
\$TFS\Dev\SomeOtherFolder\Project3
We have a main project that houses all our Assemblies. This project is the "build all" project. It is used with finalBuilder pro to perform the deployment to the next tier. The issue is that these projects are spread out all over source control. I'm not sure how to manage them.
Yes. With Team Build, not only you can build solutions across branches, you can build solutions across different team projects. However, I think the best practice is keeping each project and each branch with their own build definition.
In your case, I'd first try to organize the source tree, then define a master solution that builds all projects. FinalBuilder should support your scenario, though I think FinalBuilder is redundant when you have TFS.
My suggestion is to identify which "projects" are released and versioned independently, and have separate branching structures for each of those.
You don't want to have 2 independent projects (by independent I mean they are released/versioned separately) within the same branching structure.
The typical way to manage dependencies between these projects is to checkin the binaries from Project 1 Version X into the Project 2 "lib" folder. That way you can release new versions of Project 1 at will, but the Project 2 team can decide when and if to take a dependency on the new version.
If your various "projects" are all pieces of the one big thing that is released/versioned together, then I'd recommend just making sure they all live under some root folder (e.g. $\TFS\Dev) and branch from there.
I'm building a tool to integrate with TFS and it needs to properly parse TFS logs (from the tf.exe history command) and checkout different revisions (again using tf.exe). It works great on the test TFS server I have, but I want to test it on a broad range of large repositories to make sure my parsing works properly.
I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member.
Are there any collections of open source code hosted on public TFS servers? Are there any other publicly available servers I could use for testing?
I would suggest using svn2tfs and choose any relatively active project on SourceForge. There are plenty of projects on SF to choose from that use SVN and not CVS. You might even get a bonus out of it and help the svn2tfs project work out any kinks.
Since you mention tf history command, I assume you want to collect/parse logs on the project's (and its files) history of checkins.
So in addition to large repository, you also need a good amount of history, am I right? If yes, then here's your set of problems:
Most projects on codeplex use Mercurial, not TFS. So even if you get access, you cannot use TFS with them.
As you mentioned, they require you to a be a member for you to access the source.
Even if you get access or find a public server (unlikely), you still would need good amount of history.
If I'm correct in my assumptions so far, here's the easiest (bit tedious though) way out:
Go to any large projects's such as Nuget or Wix
revisions
Download any old revision (go back as far as you want the history for). You can download zipped src files without being a member.
In your test server, checkin the code (src) to create the baseline.
Download the next revision.
Checkout files in your server and overwrite them with the newer revision's files.
While checkin, use the history.txt (sample) to create checkin comments
Repeat this process few times.
Voila!! You now have a large repository with lot of history!
Hope this helps.
Have you tried some of the larger projects on Codeplex?
http://www.codeplex.com
If you only need read access you should be able to play around with the various repositories.
I don't have a huge amount of tfs experience, but I would assume there are migration tools that let you ingest code repositories from other products (e.g svn or hit).
If so, you might want to find a svn/git repo for a sizable foss project, and try importing that.
"I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member."
This solution appears to be the general consensus amoung SO'rs. I've read some of the Codeplex TFS connection problem threads (you linked to below) and I hope the comments in this thread resolves the issue:
Connecting to Codeplex TFS as a Coordinator or Developer.
I'm wondering if you can use git-tfs project to import an existing Git project into TFS.
Download and install git-tfs
Create a new TFS project
Clone the TFS project to a Git project using git-tfs ("git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project")
Import a existing Git project of your choice into your fresh new Git project (I don't know the command but I think it's possible).
Use git-tfs to checkin to TFS Server ("git tfs checkintool")
=> Do it makes sense ? And works ?
For more information:
http://lostechies.com/jimmybogard/2011/09/20/git-workflows-with-git-tfs/