TFS 2017 : Restructure Source Control Tree Without Baseless Merges? - tfs

Right now our Source Control tree looks something like this:
Team Project DB
|
|___ Hello World DB STABLE
|
|___ Hello World DB RELEASE
|
Team Project Framework
|
|___ Hello World Libs STABLE
|
|___ Hello World Libs RELEASE
|
Team Project Windows
|
|___ Hello World Windows STABLE
|
|___ Hello World Windows RELEASE
|
Team Project Web
|
|___ Hello World Website STABLE
|
|___ Hello World Website RELEASE
I would like to restructure it to this:
Team Project Hello World
|
|_____ STABLE
| |
| |____ Hello World DB
| |
| |____ Hello World Framework
| |
| |____ Hello World Windows Client
| |
| |____ Hello World Website
|
|
|_____ RELEASE
|
|____ Hello World DB
|
|____ Hello World Framework
|
|____ Hello World Windows Client
|
|____ Hello World Website
This is a very small example of a much larger (and thoroughly mangled) Source Control tree. All our branches/folders are in different stages of development. So things will need to be merged UP/DOWN at some point after the code has been restructured.
I've tried moving branches and folders around (obviously testing in a DEV environment) and it seems no matter what I do I always have to perform a baseless merge once I have the code organized. Does anyone know a way to do this in TFVC that will eliminate the need for baseless merges after the code has been moved?
Thanks in advance!

No, it's impossible. What you would like to do is branching/copying/moving folder/file among different projects and create a new structure.
In TFS, you could only merge to directly related branches(parent or child). There is no merge relationship between branch STABLE and RELEASE in your case.
You have to pefer a baseless merge, such as use tf merge command.
tf merge /baseless <<source path>> <<target path>> /recursive
/baseless
Performs a merge without a base version. That is, allows the user to
merge files and folders that do not have a merge relationship. After a
baseless merge, a merge relationship exists, and future merges do not
have to be baseless.
Note Baseless merges cannot delete files in the target. You can manually carry over such changes.

Related

Trying to determine why checking in files in one project, would trigger a build in another unrelated project

One of my colleagues has made some changes to a project, named "DB Conversion". There are 2 TFS builds associated with the PharmacyWarehouse project. Here's a picture so you can see what I'm talking about.
A previous TFS Administrator set this configuration up. I inherited it when he left. As you can see PharmacyWarehouse is just a folder. But the 2 builds have a Visual Studio Build step which only looks at the PharmacyWarehouse.sln file in the PharmacyWarehouse folder. I've looked at that .sln file, it only references packages, PharmacyWarehouse and UnitTests folders. I've looked at the .csproj files, they only reference those folders/VS projects.
I've looked at the DBConversion.sln and DBConversion.csproj files in the Projects | "DB Conversion" folder. It only references that folder/VS project. The files my colleague was editing are in the Projects | "DB Conversion" | Models folder.
Why would checking in changes in Projects | "DB Conversion" | Models folder cause the TFS trigger watching the PharmacyWarehouse.sln to fire? Is it because their folders and not TFS Projects?
We're working with TFS 2015
According to the screenshot, you are using TFVC version control.
Open build definition, click the tab Trigger and check the trigger field Path specification and ensure the path is $/Pharmacy Warehouse /DB Conversion
Open build definition, click the tab Get sources and check the field Workspace mappings, ensure the path is $/Pharmacy Warehouse /DB Conversion.
After configuration, if we push the changes to the folder or project DB Conversion, it will trigger this build and only build DB Conversion.

TFS Build vNext : Lot of itrace on codecoverage enable

On our build server, we have a space disk problem. After investigation, we found a lot of te.processhost.managed_xxx_xxx_xxx.itrace files in C:\Windows\Temp. It's take nearly 50Go.
There were created on a process building in TFS 2015 vNext, on the task Visual Studio Test but there are never delete automatically.
There were not created if we disable Codecoverage option (but we need this option of course).
How can we disable automaticaly creation of these files ? Or automaticaly delete these files in the process (without script) ? Any option ? Other idea ?
From TFS 2015 Update 3 (upgrade your TFS if your version is lower than this Update 3), there is a task named Delete files, you could add this task after Visual Studio Test task to delete the .itrace files.
I faced the same issue with build agents of version 2.122.1, "Visual Studio Test 1.*" and TFS 2017 Update 3.
I worked around it with a scheduled run of the following PowerShell script:
get-childitem -Path $env:SystemRoot\Temp -Filter *.itrace | where-object {$_.lastwritetime -lt (get-date).AddHours(-1)} | Foreach-Object { del $_.FullName }

How to branch my Visual Studio Online (TFS) Solution?

I have a fairly complex solution in Visual Studio 2015. It's source controlled using Visual Studio Online with TFS as the source control mechanism.
The structure is as follows:
DefaultCollection
Team Project Root
|
----Web Apps Folder
|
----Web Application 1
|
----WebApplication1.csproj
|
----Web Service 1
|
----Web Service 2
|
----Winforms Folder
|
----Winforms App 1
|
----Winforms App 2
|
----Common Files Folder
MySolution.sln
MySolution.sln is in the Team Project Root, and the solution contains all the various applications within it which are a mixture of web apps, web services and Windows applications.
The problem I have is that I am new to branching and I want to branch the entire solution, but I think that the way my SLN file is in the root will make this difficult?
What I need is to have Web Application 1 branched, and I understand I can branch Web Application 1. But in order to run it I would need to create a new solution file to contain it which would mess things up.
Is there a way I can Branch the entire solution from this scenario, or will I have to try to re-structure things somehow?
I would Create a new Folder at Team Project Root called Main (TFS Convention, SVN it's trunk, git it's master).
Then move all the items in the Team Project Root into that Main folder.
So your structure is now:
DefaultCollection
Team Project Root
|--Main
|--Web A pps Folder
|--stuff
|--Winforms Folder
|--stuff
|--Common Files Folder
MySolution.sln
Now you can right click on the Main folder and from the Branching and Merging sub-menu select Convert to Branch.
Now you can right click on Main branch, and from the Branching and Merging sub-menu select Branch...
Your structure should be:
Team Project Collection Root
Team Project A Root
Source folder
Source folder
Team Project B Root
Source folder
Source folder
You cannot branch at the Team Project Collection or Team Project Root level. You will have to move the source to a new folder first and then you can branch.

Building specific branches on Visual Studio Team Services

I have a repository in VS Team Services which is setup as :
-root
|
| -Dev (.sln)
|
| -Releases
|
| - Test (.sln)
| - Live (.sln)
Each build is working fine, however its pulling the entire repo and I just want it to pull a specific branch (Dev, Test or Live)
So I'm selecting the Solution.sln file in the dev branch...
On the Repository tab you can specify your workspace mappings, the default mapping grabs your whole repository excluding the $/project/drops folder.
By changing the first mapping to not take $/Project, but $/project/dev you'll limit the scope of the get operation. If you no longer get the root of your team project, you can remove the cloak of the drop folder, that will only raise a warning otherwise:
The next thing you should do, if you're setting this build up to be a CI build, it to specify the folders that will trigger this build on the Tiggers tab, because, again by default, CI builds will trigger on any change in the whole team project.
To allow you to keep your build definition as a template, I suggest to use the $(Build.SourcesDirectory)\MySolution.sln instead of $/project/dev/Mysolution.sln, that way you only need to update the mappings of a build definition after cloning it to another branch root or when saving it as a template.

TFS Branching and Build Definition

We have a TFS structure below. I will try my best to give scenario and what I'm trying to achieve:
Source
|- Solution 1
|- Solution 2
|- files.....
Note: Solution 2 includes both Solution 1 and 2. This means if we build Solution 2 it builds both 1 and 2.
Build Definition:
|- Build Definition Dev (Builds Solution 2)
|- Build Definition QAT (builds solution 2)
|- etc...
Now, the solution 1 is going live this week and we need to label it and branch. Whereas Solution 2 will go live in few
months time.
Question:
What is the best way to branch and Label Solution 1 so that we can
a. Always deploy the solution 1 branched for specific environment.
Do we need to create separate Build Definition?
Is there way to configure Build Definition so that it builds and deployes the branched version?
Idea is to be able to deploy the branched version for support and bug fixes and be able to deploy it to given environment. At the same time keep Solution 2 as it is.
Finally merge both Solution 2 and branched version.
Thank you.
If solution 1 is referenced by solution 2, i.e. share some of the projects then branch Source so you will have each version in a dedicated branch. If there's no project sharing, separate the solutions into seperated branches.
Option 1:
Branch 1.0
|- Source
|- Solution 1
|- Solution 2
Branch 2.0
|- Source
|- Solution 1
|- Solution 2
Option 2:
Branch 1.0
|- Source
|- Solution 1
Branch 2.0
|- Source
|- Solution 2
2. Yes. There's no reason not to.
3. Yes. This is a big one. There are many ways to achieve that. Community TFS Build Extensions and VS Lab Management can help you get started.

Resources