We are using TFS2013 and we have need to have main branch on server workspace with disabled multiple checkouts, and to have another branch again on server workspace but with enabled multiple checkouts. Is this possible in any other way than using local workspace on that second branch?
Thanks!
No. The settings for checkout are at a team project level. However, there's no good reason to have exclusive checkouts enabled in the first place -- they are a terrible detriment to productivity. If two developers change the same file, they'll have to merge the files. It's not a big deal.
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.
I want to create a new stream in TFS just like we use to do in clear case or clear quest tool by IBM. I believe we can achieve the same thing by creating a branch. I have been able to create branches but than when we create work items , we are not able to search work items for a particular branch . Work items are coming in root project only. Here is my structure
Root Project
- Main Branch
- New Branch
Am i doing it right way? Do i need to create a new project and branch there right under root level ? Like below
Root Project
- Main Branch
New Project
- New Branch
I hope i am able to clear what i want to achieve . Any TFS expert there?
TFS has work item tracking features designed to assist enterprise software development teams to manage their work and software defect tracking. Work Item is for a team project's team, not for a single project/branch (team project and project are not same thing). You can specify Area and Iteration for a work item.
Regarding TFS branch, you would never branch a team project, but branch a project. Check: Branch strategically. You can use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the
codebase
Take snapshots and then support subsequent isolated changes (for
example, to create a release branch)
In the company I work for we have a Release branch from which we publish versions to production.
I want to prevent a situation where someone checks in changes made in that branch directly without the changes were synced from the development branch.
Is there a way where I could set the Release branch to allow check-ins for change-sets which are of "Merge" type only?
By this I could ensure the change-set was originated from the development branch and achieve my goal in addition to preventing non synced code between production and development branches.
You cannot fully restrict a branch to allow merges only. But there is a checkin-policy made by a Microsoft MVP which you can configure. Combined with the checkin-policy from the TFS Power Tools you can configure it to a speficic folder. The configuration process is explained on teh download page.
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 ;)
We have 3 environments: dev, test, and staging.
I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?
Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.
Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.
Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.
You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
Even though TFS if very server-centric (compared to SVN, for example), this merging functionality happens on the client. You need to have each branch mapped to your machine. After the Merge process is completed, you'll have uncommitted changes in the target branch until you check in.
In Microsoft's vision and in the example I give here, these branches are permanent. This was a change from my previous practice using SVN, where whole branches were created/promoted/retired all the time. In the TFS way, you create the Test branch and it remains, indefinately, the Test branch. It's never promoted; its changes are merged elsewhere.
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).
Yes, this is possible, but you must manually check them in from one branch to another.