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 ;)
Related
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
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 have lots of feature branches, and we don't want to manually create a build definition for each of them for continuous integration.
Is it possible to create one build definition in TFS Build 2015 that will build solution from the branch when code is checked in to it? We are using TFVC for source control.
Preferably, only the active branches should be downloaded to the build agent, as we have a lot of old branches that don't get any check-ins.
There is a similar question about old TFS Build system, but since build system was completely changed in TFS 2015, the answer would be different too - TFS build, one build for many branches
Short answer: No.
This works for Git, not for TFVC, unfortunately.
Actually, it would appear to work out of the box with TFS 2015 Update 2, according to a test I just ran with the following simple structure...
$/Project
$/Project/Product1/Solution1/
$/Project/Product1/Solution1/solution1.sln
: (and everything below it)
$/Project/Product1/Solution1-branch/solution1.sln
: (and everything branched below it)
$/Project/Product1/Feature2/another-solution1.sln
: (and everything below it)
Build settings:
Build tab | Solution should be "**\*.sln", Repository tab | Repository should be "Project" and Mappings should include "$/Project/Product1/".
The ** in the Solution field causes it to search recursively for *.sln files, which it then builds in sequence.
I just tried this and it built all branches one after the other.
Excluding "old" branches might be more difficult if you use the single recursive approach, but you could always simply list the desired branches in the Mappings area - the nett result should be the same.
Hope that helps.
If I understand your question, this might work for you.
This will build all feature branches, plus the develop (default) branch as part of CI.
Not sure why, but if you reverse the order of these it does not work.
What will I actually miss if basing my source code handling on TFS (to get all the integration and reporting etc) but use git-tf or git-tfs locally?
Will I then be able to use the complete git functionally to branch and merge locally just as if used a git based central repository, or will there be a different workflow and limitations to consider?
We use feature and release development branches a lot and like to keep doing so, how does actually the TFS server handle this when pushing these locally using git-tf etc?
Actually, git-tfs is more advanced than git-tf. I highly advice to use it instead of git-tf (for the moment).
With git-tf, you should clone each branch as a repository (and be unable to cherrypick, merge...) while in the last version of git-tfs you can do it and keep your workflow.
See https://stackoverflow.com/a/13710811/3619
If you know git there is not problem to use git-tfs!
The documentation : https://github.com/git-tfs/git-tfs/blob/master/doc/
just know that if you use :
git tfs checkintool
or :
git tfs checkin
it will create a merge commit
and if you use :
git tfs rcheckin
it will commit each local commit in tfs and fetch and rebase automaticaly on these commits...
But read the wiki documentation, it's clear enough ;)
edit:
Contrary to what #gbjbaanb said, there is a lot of advantages of using git-tfs instead of plain TFS (if you know how to use git...). ALL what you could do with git locally works and is still an advantage (light branching, rebase, local commits, reworking commits, knowing exactly which version is checkouted, fetching and seeing changes WITHOUT merging them with your current workspace, better history,...).
Now with git-tfs, you could even create more easily than with TFS a TFS branch (you just have to create it before doing a commit in it, or rebase onto after creating it if you began your work in a git branch before... ).
The only thing that is not better than TFS, for the moment, is merging 2 TFS branches that is not supported. You should either do a merge with TFS if you want to see the merge in your history (what we generally want) or merge with git and checkin in tfs (and you won't see the merge changeset :( ).
A pull request[1] to resolve all this (and permit to manage merge commit a LOT easier than with TFS) already done and waiting for merge in the trunc (I have just to refactor Unit test and the feature be reviewed).
[1] https://github.com/git-tfs/git-tfs/pull/363
If you use git-tf (the MS version) firstly you will have to understand the commands you use will be different - they stuck an additional "tf" in every command. (eg git tf push)
The second is that branching will not work like git - I found (and this could be due to security setups and suchlike, even though I can create branches locally and on the server) that whilst you can branch your local git setup, you cannot push a new branch back to the server - you have to merge it onto an "offical" branch first.
If using TFS, I wouldn't bother trying to use any of the bridges (though svn-tfs bridge is very close due to the nature of TFS being close to SVN). I'd use the native client. I wouldn't choose TFS first though, but if that was what I had to use - the Team Explorer Everywhere client would be my choice.
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/