I have a simple structure in TFS. Something like this:
[Main]
|
---------------
| | |
[Br1] [Br2] [Br3]
The code is merged from Main to Br3 has been worked with in Br3 for a while.
Then one merge happened from Br3 to Main with a few conflicts (about 15 files) and once trying to check in on Main branch I get a huge number of files marked as changed to be checked in. I assume those are all the files in the Main branch. When randomly comparing some of the marked ones, there is no visible change between to two (even if displaying white spaces).
Anyone knows what happened here?
EDIT
How do I find out if the change would only be in the file access rights between my local and server file, and how could I ignore those kind of changes?
According to your comment. Since you are doing a baseless merge. Then its a normal phenomenon. When you did the baseless merge, every single file in the solution was marked as changed and listed in the pending changes during check in. There is no option which you can simply ignore those kind of changes.
Did you mean you want to find out 'the real changed files'?
You can try below workaround undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left. from this question Files listed as pending changes when doing merges that didn't change?
Note: This works when you only have changes to files. It will not merge any New files that you have added.
Related
I have written a before-clientcheckin script to write the predicted changeset number into certain files on a user check-in operation. The script appears to be running successfully in that the new changeset number is being written to the target files and the check-in operation completes successfully.
BUT... unfortunately on check in completion a "Changed" copy of the file still shows up in the Pending Changes window. Bizarrely, this "changed" version of the file is identical to the one that was just checked in. I can get rid of it by undoing the change, which then makes my workspace and the repository equal again, with the correctly-versioned file still intact.
It seems that although the check-in is succeeding, the modification of the file by the script after the user commences the check-in operation is marking the file as changed again - even though its contents are actually unchanged.
Does anyone know how to avoid this scenario? There's no mention of this kind of issue in the Plastic Trigger manual, and although I have seen other posts from people trying to do something similar in a before-clientcheckin script, no one seems to have encountered this particular problem.
My Plastic version is 7.0.16.2421, running on Windows 10.
Any help would be much appreciated!
In my SSIS project, I created a MAIN folder in TFS and then created 2 branches (Dev1 and Dev2) from the same package which is present in the Main.
I did some changes in the Dev1 and other changes in Dev2. Now when I am trying to merge both the SSIS Packages in the Main, it is giving error (Conflict while merging). I am able to merge only one Dev package with the MAIN package. As soon I try to merge the second Dev package with the Main, it shows conflict error.
------- Dev1
/ \
------------------------ Main
\
------------- Dev2
Conflict resolution is a common activity when doing parallel development in separate branches. It happens because changes were made to the same (set of) files and those changes have hit the same piece of code.
SSIS makes this problem larger due to the fact that it has a tendency to change the order of things in files and sometimes generates new GUIDs for activities that were already in the workflow. When this happens, it causes a lot of changes almost everywhere in the file(s).
To resolve the conflict you have to select each file that is showing conflicts and follow the conflict resolution process through Team Explorer. When you select a conflict to resolve the editor will show up with the two different versions (one showing Dev2 and one showing Main (incl the changes from Dev1)). You will need to manually select which pieces of code to retain and how the files should be merged.
Unfortunately, there is no graphical representation, so you need to be very familiar with the internal file format in order to make no mistakes. After completing the merge you can first test your changes locally. If they were merged successfully, you can check-in the changes, if you've made a mistake just undo all pending changes and perform the merge process again.
The complete steps to perform merges are documented here. The BI Developer Extensions offer additional features to Visual Studio to make working with version control easier. Especially SmartDiff can save your hide in cases where SSIS has regenerated the file structure.
A while ago, I accidentally checked in some unfinished unittest files I had changed and added in solution A together with some files that contained an actual bugfix for project B.
For some unknown reason I never noticed the checkin was going to include files from another solution so the checkin was done, after which other team members added more checkins to both solutions.
My question now is two-fold;
How can I undo the part of the checkin that hit solution A without affecting B at all
Is there a way to prevent mistakes like this from ever being possible to happen within Visual Studio (Enterprise 2015), make it impossible to checkin files not part of the currently opened solution somehow?
I think the easiest solution would be to use the ROLLBACK command, if you have installed the TFS power tools (TFPT) you should be able to do it within visual studio.
In your current branch, get the latest version from server then view history and find your changeset. Then right click and select "Rollback entire change set".
This will rollback the changes in your local workspace and checkout the file. (If there are conflicting changes you will have to resolve conflicts.)
Now when you are ready to check-in, exclude/undo the files which you don't want to rollback.
Commit/checkin the files which you want to rollback.
I haven't seen a better way of doing this, and think that this is much better than individually rolling back each file in the change set.
Now to answer your second question: check this ANSWER which I wrote a while back. I am copying it here for convenience.
As far as I tested, this default setting is controlled by the following registry entry. If the value of this registry entry is set as 1, then it should change the default behavior to filter by "Solution Changes".
"HKCU\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl"
Name: FilterPendingChanges
REG_DWORD
Value: 1 = Show Solution Changes
Value: 0 = Show All
We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].
In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?
We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.
For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.
Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.
The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.
Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.
e.g. you have a Team Project that looks like this
$/TeamProject/Main
You then create a branch from "Main" called "Dev"
$/TeamProject/Dev
You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder
$/TeamProject/Development/Dev
OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"
The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.
The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)
This Blog goes in to some more detail
The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.
So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.
Try this:
select all pending files
on context menu click 'Undo...'
in the 'Undo Pending Changes' dialog sort files by 'Change' column
deselect all files except 'merge' using shift+click
click button 'Undo Changes'
From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.
When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.
I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).
When I merge files from one branch to another and then go to check in files into the target branch, there are MANY files checked out, just the ones that changed. For example, Main and Critical branches were the same and we made changes to only 2 or 3 files on the Critical Fix branch. I then merged Critical ==> Main, and when I went to check in changes to the Main branch I noticed that there were numerous files checked out, not just the 2 or 3 that were actually changed in the Critical Fix branch. Moreover, when I compare a file from the Main branch to one on the server, I am told that the files are identical. If the files are identical, why are they checked out? Any help would be appreciated, or even a link that explains how TFS 2010 does merges.
The default Source Control Merging tools in Visual Source Safe and then TFS have always been rather poor - they are often confused by the simplest changes, often detect identical files as being "changed", and the auto-merge facility frequenty fails (includes the wrong changes). I quickly learned distrust for these merge tools (in about 1995) and have not seen any evidence in any of the new releases since then that the core merge algorithms have been improved at all.
The good news is that you can replace the client-side merging tools with third party ones (I use one that works so well that I actually trust its auto-merge option. I once spent 2 days trying (and failing) to do a complex merge with the TFS tools and in the end bought this 3rd party tool and re-did the entire merge successfully in 15 minutes!)
The bad news is that the first step of branch merging just uses the TFS merge code, and so it gets confused a lot, resulting in the symptoms you've described. This is frustrating in such a key feature of such an expensive application as it wastes a lot of programmer time on every merge to fix imaginary "conflicts" - on the plus side, with the help of 3rd party tools it is usually very easy to reliably resolve these merge issues.
I have had the same problem. I created a branch of our DEV branch and made changes to a few files. I checked in my changes and merged the latest changes to DEV into my branch. After the merge all 30,000+ files in my branch were marked as changed. Just like cju, I found that a comparison of most of the files showed that no changes had been made.
I decided to undo all changes and try again. When I right-clicked on the solution and selected Undo, I got a message that one file had changes, was I sure I wanted to undo that file? I clicked "No to All" and when the undo operation was complete, only the files that had been changed during my merge from DEV were still checked out. This was exactly what I wanted so I checked those changes into my branch and continued working.
I hope others can correct their situation as easily as I was able to.
One thing I noticed is that when one file is changed in different branches resulting in exactly the same content, then merging marks it as a conflict since the file is changed in both places. Of course a difference view of the file notices that there are no changes and therefore an auto merge solves this automatically for you.