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.
Related
EVERY SINGLE TIME I unshelve a changeset with add/rename/move/remove changes or
have pending changes with such changes, I have to manually merge the parent project file which receives a lot of activity (the majority of the codebase is nested under the one project so its project file's version changes very frequently).
This is a multiple-times-per day frustration and it seems that TFS should be able to do this for me since the changes are simple (e.g. remove the line for the deleted file in latest version and add the line for the new file in local version). I conclude this because it behaves intelligently in this way for code files to automerge versions.
So why does automerge behave differently with project files than with code files?
For example, developer A creates a changeset adding a file to the project and shelves it for review. Then another developer B checks-in changes to the project that also adds a file (unrelated), so when I go to unshelve developer A's changes I have to resolve conflicts on the project file.
Also, if a group of files are moved/renamed/added and I want to unshelve with only a single affecting change, it is much easier to just take the server version of the project file and manually reapply the single change (e.g. add existing file) instead of merging a dozen spread out changes across thousands of lines. (And god forbid you have a rename change and took server version of the project file, because then you need to manually edit it with a text editor to rename otherwise you'll get a sequence of errors due to the renamed file already existing on disk when trying to rename from solution explorer).
Update: I'm escalating this, because now it's screwing us over.
Using VS2014 and our codebase mostly lives under one giant database project (*.sqlproj).
Most likely, different files get added on the same line in the file since in most cases, project files are auto-generated, unlike regular code, it is hard to tell in which line VS would insert a new file item when someone adds it on the front end. If 2 people add new items to the project at the same time, it is very likely that you will get 2 versions of the project file with these new items written on the same line, which will cause the conflict. Sometimes, (e.g. if you add reference), it's more than one line per item, which makes merging even worse.
I would suggest that each developer that makes changes to the project file, checks it out with the lock (exclusively), so there will be one change at a time. Also, make sure other developers get latest before making their change (there is a setting in Visual Studio under Tools > Options > Source Control > Visual Studio Team Foundation Server). This will make auto-merge work.
Yes this is one of the Doh! Damn! I shot myself in the foot. I don't have a lot of experience with TFS in large teams, but I'm facing this issue.
During a transition to new equipment, a developer forgot to check-in some code. Work proceeded on the new laptop for several weeks before noticing that the previous work was not checked in. Mutliple check-in have occured.
I have recovered the files from the old laptop, and have them on my current laptop. What is the best way to merge in these changes? Do I create a branch, merge in these changes, and then rejoin the branch?
Is there a "cookbook" out there that details what should happen when faced with various situations?
We are using TFS 2010.
Thanks in advance...
Creating a branch here is probably a little bit heavier-weight than what you need for this one-off situation. If it were me, I would do this:
Set up a workspace on your computer with the appropriate mappings.
Do a Get Specific Version to the version that the other computer was at. The best case scenario is if the user never deleted their workspace on the server. Then you can simply specify their workspace as the version and you'll get the files as they existed on the laptop. (You can specify this as Wworkspacename;owner name.) If the user deleted their workspace, you can get based on the changeset number they were at, or based on the date they were working at.
Copy the recovered files on top of the new TFS workspace.
Run tfpt online from the Team Foundation Server Power Tools. This will examine the local filesystem against the server and determine what changes were made. You may wish to examine the options, notably the /diff flags (which performs MD5s on the file instead of simply examining the readonly bit), and the /deletes and /adds flags, which detect deleted and add files, respectively.
Do a Get Latest on your workspace, resolve any conflicts, and check in.
You can follow this sequence to try out:
Make a merge-branch of your code version based on the time-stamp of where your restored laptop code has left the version control system.
Get your branched code to a location on disk.
Perform a check-out for edit of the entire workspace.
Copy the old restored code over the files in this workspace.
Perform a checkin of the local code into the branch.
Merge your latest code (main trunk) into the branch, merging changes, solving conflicts.
If all build and tests out correctly on the merge branch, merge that branch back into the main.
That should do the job.
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.
Our project has hit a point where we need to split off some code into a separate team foundation project. We would like to move these files so they retain their version control history. Temporarily we are copying the files back to the original team foundation project and re-adding them just so that our daily build & test process doesn't break. As we are able to modify our build & test process we will start to remove these temporary copies.
One issue we are noticing is that we have a nightly script that checks various maintenance branches to see if there are changesets that haven't been merged back to trunk. It is now whining about changesets that have been merged before. These changesets seem to be related to the files that have been moved and re-added. Any ideas as to why we are seeing this and how we can discard these merge candidates? If we do a merge /discard TF tells us "there are no changes to merge". It seems to be confused. Also are there other problems we might run into with this approach? Perhaps there is a better approach?
The solution that I found was to merge /discard all other changesets, then do a "catchup" merge /discard i.e. not specifying any version info. This generated a number of merge related pending changes but when I went to check them in, I got a TF14088 error. The workaround for this error was to checkin just the problematic files/folders first and then check in everything else.
This question is a derivative of a previous question: How to version resources that are shared across projects
I have a project that contains code that is consumed by many other projects. Specifically, one folder in this parent project has been branched to dependent child projects.
We have since made changes in the parent project and checked them in. In Source Control Explorer, I right click on the branched folder in the parent project and select "Merge", intending to push the changes to a dependent project. I select the child project as a destination and then select "Latest Version". The wizard informs me "There are no changes to merge."
From my perspective, this isn't true, since the recently updated files are clearly different.
Is there a fundamental misunderstanding of the merge process in TFS here? What do I need to do differently?
The TFS merge engine relies almost entirely on history, not file contents. This makes it efficient for very large trees, and flexible for tasks like safely cherry-picking changes -- but it also makes answering your question difficult.
The first step is to understand the diagnostic commands tf history, tf merges, and tf merge /candidate. Here is a good introduction: http://blogs.msdn.com/dstfs/archive/2009/04/15/a-note-on-merging-and-the-use-of-tf-merges-tf-merge.aspx
If you are new to branching & merging in TFS then your history is probably not very complex. I think it's likely you'll find your answer with one quick call to tf merges. However, tracing merge history can become extremely convoluted in the general case, so if you have trouble feel free to post back with more details.
Go to one specific file you know has changed in your "parent" project. Try merging just that file. Don't check anything in; just see what happens.
Something to watch for: The merge tools will not include files that have been added after you branch. You have to branch new files explicitly before you can merge any further changes. If a file is added to both parent and child folders without using a branch operation, the merge tools don't treat them as versions of the same file (and you can't merge changes between them).