I recently moved from a svn shop to one that uses TFS. One of the issues I'm having in using the TFS merge is ignoring files. Our branches have several files that we never want to merge(version info, ivy files etc) and we have to manually uncheck them each time we run a merge. I know in SVN there is a file property you can set to ignore files during a merge, does TFS have anything similar?
Thanks in advance
From the command line, you can use something like the following:
tf.exe merge /discard <path to the file to exclude>
That will update the merge history as if the file had been already merged, so it won't continue appearing in the merge candidates list.
Related
I need to branch and merge hundreds of files and the only way I know is to do it manually one by one.
Is there an automated way where I can just list all the file names with their path, add change set, and indicate the destination for it all to run by itself or better yet since the files have similar names (project id), an condition where it should go.
You can branch and merge at the folder level. You do not need to branch and merge individual files, you can branch and merge a folder that contains all of the required files.
I'm taking code from a 3rd party, and modifying it. The 3rd party puts out occasional releases, as a zip file, I want to keep my branch, stored in Team Foundation System, up to date with theirs. But I don't see any point of keeping their main trunk in my source control, just so I can merge it into my branch. Is there any way I can just do some kind of baseless merge from their files I download into my TFS branch?
I tried this:
tf merge /baseless "C:\localpath\to\third-party-release-2.0" "C:\localpath\to\mybranch"
and this:
tf merge /baseless "C:\localpath\to\third-party-release-2.0" "$/serverpath/to/mybranch"
and both tell me
No appropriate mapping exists for
C:\localpath\to\third-party-release-2.0.
The merge command applies changes from one branch into another.
According to your command, you are trying to merge something from local to your server branch. This is not supported in TFS. You may need to check in your C:\localpath\to\third-party-release-2.0 into TFS source control first. More info about tf merge command from MSDN.
I have recently discovered that I was using my third party diff/merge tool incorrectly when resolving conflicts encountered merging from the trunk to my team branch. As far as I know, only files that were merged in the merge tool were affected. I know how to use tf merge /force to re-do a merge, but I don't want to re-merge every file if I can avoid it, just the ones that I had to merge manually. Is there any way to get a list of such files now, long after the merge changesets have been checked in?
Unfortunately, TFS does not track any data about which files were resolved using a merge tool. Whether a file was merged manually or automatically it is still just recorded as a "merge" in TFS.
having a weird problem with TFS (TFS2008). We've done a merge into our Main trunk. We've resolved the conflicts and we've checked in associating it with a single work item.
So we have our WorkItem with a single changeset in it.
Our build is failing because the previous version of the csproj file is being got from TFS. If I open the WorkItem and the go to links and open the changeset the csproj file is not listed. In fact no files that are "merge/edit" are listed... there are others missing the csproj is the first.
If I do a view history on said csproj file I see the last changeset it was in. If I open that changeset (same number as associated with the work item) the csproj file is there present and correct, along with all other "merge/edit" files.
If anyone has any ideas why this might happen and how to resolve it, it'd be much apreciated.
Thanks
If you do a view history on the MAIN trunk, and look at the changeset that you merged from your development branch, does the CSPROJ show there? It sounds like it may have not been picked up in the merge.
If it does show in that changeset, is there any chance that there was a conflict when you merged? If so, we've had the issue where the person doing the merging inadvertently chose to keep the target version. In that case, the conflict is resolved, and as far as TFS is concerned, there's no longer a need to merge that file.
If you have a list of the files that seem to be missing, and trying an additional merge isn't picking anything up, you can force the merge from the command line (something like):
TF.EXE merge /force /version:T "$/Project/Dev/Src/FileThatWasMissed.csproj" "$/Project/Main/Src/FileThatWasMIssed.csproj"
Of course, remember to change your filename and make sure you are in a mapped directory when you execute this command.
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.