so this is what I have
valid changeset id 8
valid changeset id 7
valid changeset id 6
valid changeset id 5
invalid merge from branch X changeset id 4
valid changeset id 3
valid changeset id 2
valid changeset id 1
is there a way to "delete" or "skip" or "ignore" the invalid changeset?
if not then I will lose a week to recover from this mess.
To answer the question "Is there a way to skip or otherwise ignore a changeset?" The answer is no.
Which leaves you with three choices:
The first is to pull all the changes you want from 5 through 8 and rollback to 3. Basically, get the files that changed and hand merge them into rev 3.
The second is to look at everything that the merge updated and hand rollback those items. In short, depending on the number of files involved you are in for a long editing session.
The third option is only available to you if sets 5 through 8 did not modify the same files as 4. If this is true then just select the files from the 4th set and roll those back individually. Then check in the new set as #9. Somehow I doubt this is available to you.
If you use TFS 2010 then you can use the tf rollback command, this will attempt to remove the offending chagngeset. If there are conflicts because subsequentchangesets have modified the same code then the merge tool will appear and you can select the code you need to keep / remove.
For earlier versions of TFS you can install the TFS power tools and use the tfpt rollback command to do the same thing
Related
I am trying to query items(Features, User-Stories, Tasks) that were moved from current iteration to a different iteration (like next iteration), for our team to see which items we didn't accomplished in the current iteration.
Is there a way to do this in TFS?
My TFS Version is 2017 Update 3 RTM
You can track the progress of requirements, bugs, and other work to be completed in the current sprint using the #CurrentIteration macro.
Any item assigned to a sprint which corresponds to the current iteration path for the team will be found. For example, if a team is on Sprint 5, then the query will return items assigned to Sprint 5. Later, when the team is working in Sprint 6, the same query will return items assigned to Sprint 6.
Note
For the #CurrentIteration macro to work, the team must have selected
an Iteration Path whose date range encompasses the current date. For
details, see Define iteration paths (aka sprints) and configure team
iterations. Also, queries that contain this macro are only valid
when run from the web portal.
See also Client restrictions on the use of the #CurrentIteration
macros later in this article.
After exclude those current iteration items, you should be easy to determine those items you need and then you can check the history of these work items which the previous iteration path they are.
One tip is to have a habit of tagging work items with sprint name eg. "P27" from which they were moved to an other sprint. Then it is easy to query. Even though this requires some manual routine tagging ...
We are planning a migration from an on-premises TFS instance to VSTS very shortly. Ahead of the migration, we run the pre-requisite Validation task and obtained the following output report on the TPC database size:
"The database is currently 191GBs. This is above the recommended size of 150GBs to use the DACPAC import method. The largest table size is currently 172GBs. This is above the recommended size of 20GBs to use the DACPAC import method.
Validation completed 'Validate Collection Database Size' with result Warning, message The largest table size is currently 172GBs. This is above the recommended size of 20GBs to use the DACPAC import method."
We are therefore keen to reduce the size of the TPC database and have two main considerations:
Shrink the Database and generate the DACPAC from the resultant output.
Delete any of the following objects which are unused or redundant:
a) Older Workspaces
b) Build Results
c) Redundant Team Projects
d) Unused Files
e) Test Attachments created during test runs
f) XAML Builds
Would therefore appreciate some advice or feedback on the pros and cons of either approach and which would be recommended.
Given that you need to reduce your largest table by 150GB, I wonder whether DACPAC is every going to be an option. That said, it's always a good idea to clean up your TFS instance. Your first step won't help a lot until you've managed to strip enough data to actually get any benefit out of a shrink.
Your identified actions would indeed help, most are already documented here. Queries that can aid in detecting where your space is allocated are also found in this recent support ticket.
Delete old workspaces
Deleting workspaces and shelvesets can reduce your migration and upgrade times considerably. either use the tf commandline or leverage a tool like the TFS SideKicks to identify and delete these.
Build results
Not just build results, but often overlooked the actual build records can take up a considerable amount of data. Use tfsbuild destroy (XAML) to permanently delete the build records. In the past, I've encountered clients who had 1.8 million "hidden" builds in their database and removing them shaved off quite a considerable amount of data. These records were kept around for the warehouse.
Old team projects
Of course, destroying old team projects can give back a lot of data. Anything you don't need to send to azure helps. You could also consider splitting the collection and to leave behind the old projects. That will give you the option to detach that collection and store it somewhere, should you ever need that data again.
Redundant files
Deleted branches are a very common hidden size hog. When deleting things in TFVC, they are not actually deleted, they're just hidden. Finding deleted files and especially old development or feature branches can give you back a lot of data. Use tf destroy to get rid of them.
You may also want to look for checked in nuget package folders, those can quickly rack up a lot of space as well.
Test Attachments
Ohh yes, especially when you use test attachments, these can grow like crazy, depending on your TFS version either use the built-in test attachment cleanup features or use the Test Attachment Cleaner from the TFS power tools.
XAML Builds
The build definitions themselves won't take a lot of db space, but the build results may. But those have been covered in a previous section.
Git Repositories
You may have data in your git repositories that are no longer accessible due to force pushes or deleted branches. It's also possible that certain data in Git could be packed more efficiently. To clean your repositories you have to clone them locally, clean them up, delete the remote repo from TFS and push the cleaned copy to a new repository (you can use the same name as the old one). Doing this will break references with existing build definitions and you will have to fix these up. While you're at it, you could also run the BFG repo Cleaner and convert the repositories to enable Git-LFS support to handle large binary files in your repositories more elegantly.
git clone --mirror <<repo>>
# optionally run BFG repo cleaner at thi s point
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git repack -adf
# Delete and recreate the remote repository with the same name
git push origin --all
git push origin --tags
Work item (attachments)
Work items can gather up a considerable amount of data, especially when people start attaching large attachments to them. You can use witadmin destroywi to delete workitems with unreasonably large attachments. To retain the work item, but delete its attachments you can delete the attachments from the current work item and then clone it. After cloning, destroy the old work item to allow the attachments to be cleaned up.
Old work items that you no longer need (say the sprint ites from 6 years ago) can also be deleted. My colleague Rene has a nice tool that allows you to bulk-destroy by first creating the appropriate work item query.
Be sure to run the cleanup jobs
TFS often doesn't directly prune data from the database, in many cases it just marks stuff as deleted for latest processing. To force the cleanup to happen immediately, run the following stored procedures on your Project Collection database:
EXEC prc_CleanupDeletedFileContent 1
# You may have to run the following command multiple times, the last
# parameter is the batch size, if there are more items to prune than the
# passed in number, you will have to run it multiple times
EXEC prc_DeleteUnusedFiles 1, 0, 100000
Other useful queries
To identify how much data is stored in each section, there are a few useful queries you can run. The actual query depends on your TFS version, but since you're preparing for migration I suspect you're on TFS 2017 or 2018 at the moment.
Find the largest tables:
SELECT TOP 10 o.name,
SUM(reserved_page_count) * 8.0 / 1024 SizeInMB,
SUM(CASE
WHEN p.index_id <= 1 THEN p.row_count
ELSE 0
END) Row_Count
FROM sys.dm_db_partition_stats p
JOIN sys.objects o
ON p.object_id = o.object_id
GROUP BY o.name
ORDER BY SUM(reserved_page_count) DESC
Find the largest content contributors:
SELECT Owner =
CASE
WHEN OwnerId = 0 THEN 'Generic'
WHEN OwnerId = 1 THEN 'VersionControl'
WHEN OwnerId = 2 THEN 'WorkItemTracking'
WHEN OwnerId = 3 THEN 'TeamBuild'
WHEN OwnerId = 4 THEN 'TeamTest'
WHEN OwnerId = 5 THEN 'Servicing'
WHEN OwnerId = 6 THEN 'UnitTest'
WHEN OwnerId = 7 THEN 'WebAccess'
WHEN OwnerId = 8 THEN 'ProcessTemplate'
WHEN OwnerId = 9 THEN 'StrongBox'
WHEN OwnerId = 10 THEN 'FileContainer'
WHEN OwnerId = 11 THEN 'CodeSense'
WHEN OwnerId = 12 THEN 'Profile'
WHEN OwnerId = 13 THEN 'Aad'
WHEN OwnerId = 14 THEN 'Gallery'
WHEN OwnerId = 15 THEN 'BlobStore'
WHEN OwnerId = 255 THEN 'PendingDeletion'
END,
SUM(CompressedLength) / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
WHERE r.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC
If file containers are the issue:
SELECT CASE WHEN Container = 'vstfs:///Buil' THEN 'Build'
WHEN Container = 'vstfs:///Git/' THEN 'Git'
WHEN Container = 'vstfs:///Dist' THEN 'DistributedTask'
ELSE Container
END AS FileContainerOwner,
SUM(fm.CompressedLength) / 1024.0 / 1024.0 AS TotalSizeInMB
FROM (SELECT DISTINCT LEFT(c.ArtifactUri, 13) AS Container,
fr.ResourceId,
ci.PartitionId
FROM tbl_Container c
INNER JOIN tbl_ContainerItem ci
ON c.ContainerId = ci.ContainerId
AND c.PartitionId = ci.PartitionId
INNER JOIN tbl_FileReference fr
ON ci.fileId = fr.fileId
AND ci.DataspaceId = fr.DataspaceId
AND ci.PartitionId = fr.PartitionId) c
INNER JOIN tbl_FileMetadata fm
ON fm.ResourceId = c.ResourceId
AND fm.PartitionId = c.PartitionId
GROUP BY c.Container
ORDER BY TotalSizeInMB DESC
We have a changeset where the developer has checked in changes to both source and target branch, many changes including renames in both branches. The merge of the the changeset from source to target branch goes fine, but the changeset remains in the list of changesets to be merged.
When I now try to merge the changeset again, it says "There are noe changes to merge.". And the changeset remains in the queue.
We have tried to use the command line tool to discard the changeset like this:
C:\src\project\sourceBranch>tf merge /discard /recursive /version:C8137~C8137 $/Project/sourceBranch $/
Project/targetBranch
This did not help. We have also tried using other options like /force and /baseless with no luck.
What other possibilities are there of getting rid of the changeset among the merge candidates?
Ok, so basically you have a changeset with items that belong to two branches that are directly related. Which makes the merge of such changeset using the "partial changeset" subcomponent of the changeset.
Let me explain with a better way:
CS1234 (your changeset)
Partial CS1234A for branch A (say the source branch)
Partial CS1234B for branch B (say the target)
You did a merge from A to B, which merged CS1234A to B.
Now when you attempt a new merge still from A to B, you still have CS1234 as a candidate, right ? Then if you select it, nothing is done, which is totally understandable due to the fact you already merged CS1234A and CS1234B does not belong to the source branch (A).
Looks like a bug from TFS to me that I already ran into, I thought Microsoft fixed it with the TFS 2010 RTM, apparently not.
Basically TFS gives you CS1234 as a candidate because only a partial part of it was merged, but as the other partial part can't be merge, it doesn't make sense to give it as a candidate.
What about:
You initiate a merge from B to A (in the reverse way), does CS1234 is given as a candidate ? My assumption is if you merge CS1234 from B to A then you won't be bother again with this changeset when you'll display the candidates from A to B. But I don't know if it's something you're willing to do.
Anyway you should fill a bug at the Microsoft Connect site
I moved from Subversion to Microsoft's Team Foundation Server for version control, and it is my understanding that you cannot merge discontinuous change-sets in TFS.
For example, I have a file called "baseline.txt" that looks like this:
line one
Then, I branch the file to a new file called "branch.txt", and then do two check-ins on "baseline.txt" so that it finally looks like this:
line one
line two //checked-in change-set A
line three //checked in change-set B
Now, I want to merge only change-set B into "branch.txt". In other words, I expect "branch.txt" to look like this after the merge:
line one
line three //checked in change-set B
Basically, I want to skip change-set A and merge change-set B. It is possible in Subversion, but in TFS if I want to get changeset-B, I have to also get all change-sets "up-to" B.
Is this true? That's what my experiments show, but "Understanding ChangeSets and Merge with Team Foundation Server" seems to indicate differently.
That article is confusing, and I don't believe it is accurate. When the second change is checked in, it should generate a merge conflict. At that time, you would need to resolve the conflict in one of three ways:
Merge the changes
Overwrite with the new changeset, or
Keep the old, and discard the new changes.
No matter what, when you get ready to merge back to baseline.txt, you have a "point-in-time" version of the file that you're going to check in.
Is there a way in TFS in VS2010 to specify that a particular iteration is the current one, and then return that for use in queries similar to the way #Project works? If not is there a way to do sub-queries in TFS work item queries?
Looks like Microsoft listened. #CurrentIteration is being added as a token.
That’s great, of course. When looking to write a query against the current sprint, however, you are in danger of losing sight of unclosed work items in previous sprints. When you reach for #CurrentIteration, you probably just mean “all unfinished work that has been committed to a sprint.” If you filter to a single sprint, you’ll miss any stragglers you failed to close or move forward from previous sprints.
Consider using the following pattern, where “ScrumOfScrums\Release 1.0.0.0″ is your backlog path, and all of your sprint paths are children to that:
Filter for work items under your backlog iteration node, but not equal to the backlog iteration node. That will give you all items committed to a sprint.
This will also catch any items that weren’t closed in your previous sprints. Since the goal is to close every item in a sprint before moving to the next one, this query pattern will generally be better than using #CurrentIteration, unless you're looking to find the closed items in the current iteration.
P.S. While this is an old question, it was my top hit when I searched for info on querying the current iteration in TFS.
I'm afraid that there is not such a macro. I personally just have a few "X in current iteration" team queries and then edit those queries to point to the new iteration path at the start of each iteration.
I am going to try using a standard name for the current iteration such as 'Current'. The queries for this iteration would all reference this name. Once the iteration is completed, I will rename it using a naming convention that includes the date for example and the next iteration would then be created with the name 'Current' (or renamed to this if it already exists). The queries would then return results from the new iteration.
- 2010-49
- Current
- 2010-51
I am not sure whether renaming iterations this way will cause any conflicts or confuse the data warehouse for example but this would save on having to create or modify a heap of queries at the start of each iteration.
I would be very interested to hear feedback on this approach!
Query for Sprint in a date interval as shown here:
Team Project = #Project
And Work Item Type = Sprint
And Start Date <= #Today
And Finish Date >= #Today
I have found that Telerik's free Work Item Manager provides an elegant solution to this problem.
Just define your queries as you usually would but leave out any filters relating to iterations (note that this also applies to areas). There is a treeview pane named 'Area/Iteration Filters' that will add extra, recursive filtering based on the iteration (or area) that you select there.
Note that if the pane is not visible then you can enable it via the View menu.