Both Team Foundation Server (TFS) 2005 and 2008 lose history (check-ins + comments) on files when they branched and merged back. So e.g. if changes in a branch are made then merged back to the root branch, none of the changes made in the branch are visible in the root branch. The only thing visible in the history states that a merge occurred.
Does anyone know if there is an option which can be set to retain the history, or a different way to do the merge which keeps the history?
You are correct that TFS does not track history by default when merging. There is a powertool, however, that allows you to do so (see History Command under TFS Power Tool Commands).
See this comment for more details:
“If TFS would only maintain the history of branched files, rather than starting them from scratch every time a branch is done, then a similar safe merge would be possible between branches”
You can install the Power Tools and then use the /followbranches flag to retrieve the history information: http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx
History Command
Use the history command to display the revision history for one or more files and folders. The /followbranches option returns the history of the file branch's ancestors.
There is also a codeplex project to enable the option in the GUI:
http://www.codeplex.com/TFSBranchHistory
TFS Branched History plugin for VS2010 is now available from Microsoft Gallery:
http://visualstudiogallery.msdn.microsoft.com/7d4f37b6-f9a4-44c6-b0a0-994956538a44
This plugin is just query history from different branches and make union of the records.
The TFS Branched History plugin from Microsoft Gallery only works with VS2010.
For those using Visual Studio 2008, here is a plugin that provides the same functionality.
After you install it, open up VS2008 and go to the TFS Source Control window.
Right-click on an item and you will see a new option in the context menu called "Branched History".
Click on this to get the history of the item in all previous TFS branches. Give it a few seconds if you're on a slow machine.
In the "Branched History" window you can also View or Compare file versions just as you can in the regular "History" window.
Related
I'm using Eclipse importing TFS projects, one project is:
$/product mapped to C:\dev\product
I opened a branch and started working on different workspace:
$/product-branch mapped to C:\dev-branch\product
I worked on each project successfully
But now in branch in TFVC Pending Changes I see changes I made (checkouts) also in C:\dev\product ($/product)
Why am I seeing such changes and How can I separate those branches when I switch to different workspace?
EDIT
My TFS 2010 is using server workspace.
A TFVC workspace is the container for all of the work that should be grouped together (think of it like the contents of a Git repository). Now if you open a sub-folder of a Git repository in Eclipse and you've made changes at a folder that's higher up (that is, one you didn't explicitly open), the Git SCM still shows those files. It doesn't only show the files modified for the folder that you've got open. That's the same behavior as what the TFVC support is currently showing.
If you are using server workspace and checked out work under a different workspace, it will also show pending changes in pending changes list. Take a look at this similar issue: https://stackoverflow.com/a/423439/5391065
As a workaround, you could temporarily exclude no need changes in another branch to exclude list.
I'm new to using github with visual studio 2015 plugin and I'm stuck.
I created a new project on github and was able to link the depot to my visual studio project. I was able to sync some code up to the depot.
Then I added a readme file to my project on github from the website. Next day I made more code and decided to sync it up to the depot, but now it says that I have incoming commits (the readme file). I clicked on fetch on the incoming commit but nothing happens. I clicked on pull and it says my changes would be overwritten by merge.
I then went to outgoing commit (the ones i just made) and click on push. it says that "You cannot push branch master to remote origin because there are new commits in the remote repository’s branch. Pushing this branch would result in a non-fast-forward update on the branch in the remote repository"
i click on several things and i still can't resolve this issue. I want to update my current project with the readme and then update my depot. (i also am new to the terminology)
The trouble is that you've got changes on the server, that are committed, and changes to some of the same files on your local copy that conflict with it to the extent that Git can't figure out which ones should "win".
You'll have to look at each file that has conflicts, understand where the conflicts are, sort them out, tell git that you've sorted out the file, and then progress.
So Fetch will bring all of the changes down from github, locally, but not change your working copy.
Merge is intended to pull down the changes in your current branch and merge them in (and that's where it's having trouble).
Best recommendation for working with git (whether Visual Studio or not)): Fetch and merge often. Every day at least.
This page looks like a reasonable tutorial on how to do it. It looks similar to my VS2015 git plugins.
https://msdn.microsoft.com/en-us/library/dd286559.aspx
This page is quite a good tutorial on doing it from the command line:
https://easyengine.io/tutorials/git/git-resolve-merge-conflicts/
(But I've got to say: the Visual Studio tool makes it easier).
So the key points are:
look at each file and fix the conflicts.
tell git that you've fixed the file
Once you've done all the files, you need to "commit the merge"
Then you're in a place to commit your local changes and push them up to the server.
Second tip: Most people that I know who use git with visual studio also use the command line client extensively, and usually have an additional gui client (such as Atlassian's Sourcetree) as well. I use all three every day.
Is it possible to merge changes across projects in TFS 2012? If so, it doesn't seem obvious to me how. I find myself needing to do this because we created a new project when we really should have created a branch (or reorganized our branches).
You can use baseless merging from within the IDE (select merge) or using the TF command line utility. The following image shows a merge from team project Area 52 to team project Area 51, where no branch relationship exists. The IDE correctly identifies the merge as a baseless merge:
Caution is advised though and I recommend you read the section on baseless merging in the Branching Guide (http://vsarbranchingguide.codeplex.com/) first.
I did quick test and documented the findings here in a rough format: http://blogs.msdn.com/b/willy-peter_schaub/archive/2012/12/13/faq-branching-is-easy-but-can-i-merge-without-branching.aspx
Yes you can, you have a couple of options. If the code is distinct e.g. you have something like this.
$/TeamProject1/Main/Source/Solution1
$/TeamProject2/Main/Source/Solution2
And you want to branch solution 1 across to team project 2 then you can just use the "branch" functionality in the Visual Studio UI. Put the appropriate path in the "target" textbox and you should be good.
If you have the same code in 2 separate team projects then you will need to do a baseless merge. e.g.
$/TeamProject1/Main/Source/Solution1
$/TeamProject2/Main/Source/Solution1
Open up a Visual Studio command prompt and navigate to your TFS workspace, then use the following command
tf merge $/TeamProject1/Main/Source/Solution1 $/TeamProject2/Main/Source/Solution1 /baseless /recursive
This will merge the 2 versions of solution 1. Be aware though that you may get problems if files have been renamed or deleted. TFS will also probably treat each file as a merge conflict (unless the content is identical) and you will manually need to decide which files (Source or Target) to overwrite / merge.
Once the baseless merge has been checked in then a merge relationship will be created and any further merges will be able to be done from the IDE.
I'm using Eclipse Indigo SR2 with the (built-in) EGit plugin v.1.3.0.201202151440-r and haven't been able to find any way to easily review all my changes before making a commit.
I used Eclipse with SVN for years, and this was always very easy to do. I would typically right-click on my project, select Team->Synchronize, double-click on the first changed file (in the Team Sync perspective), then hit Ctrl-. repeatedly to review all changes in one file, and then proceed to the next file, as I wrote a summary of my changes for the commit message.
But of course, git is very different from Subversion, and so my workflow must change. With EGit, "Team Sync" only appears to be useful for reviewing changes between my local files and the remote repository (i.e. before a push to the remote). I need a way to review changes since my last commit to my local repository. I generally don't even care to (re)review changes before a push to remote (and if I did, I'd prefer a simple equivalent of git log to see what commits I'm about to push).
If I right-click on my project and select Team->Commit, I am presented with a window that does almost everything I need to do (select files to stage, commit, write a commit message, amend a previous commit, etc.). What it doesn't allow me to do is quickly and easily review all my changes in a compare editor. I can't believe this capability doesn't exist! It seems I am required to double-click on each individual file, review the changes, close the compare editor, and double-click on the next file. That's ridiculous!
TL/DR - I am looking for a simple GUI equivalent (in Eclipse) to do what I am easily able to do from the command line using git vimdiff (where vimdiff is a git alias that uses vimdiff as the "difftool" to cycle through all modified files) followed by git commit (with perhaps a git add or two in between).
If no one has a good solution, I am curious about how others handle their commit workflow with EGit. I've been getting along fine committing from the command line (not that Eclipse is happy about that) but I can't believe that EGit is as near-useless as it seems to me. Perhaps my google-fu is not as strong as it once was?
Says here that you can see the diffs between the working tree and any given reference. Perhaps you should try out the latest version (Juno) of Eclipse/EGit and see if it's gotten any better?
Update: I've tried this out in the latest Eclipse, and as far as I can see it works fine. Here's how:
In the moment of writing this, Eclipse Juno 4.2 is the version you should go for. On the download page, you can pick between several packages according to your needs. The 'Eclipse IDE for Java Developers' comes bundled with EGit, but you can also install EGit into any distribution using the Eclipse Marketplace (under the Help menu).
Once you've imported your project into Eclipse, make sure the project is "shared":
Right-click project -> Team -> Share Project.. -> Git
Now do the following:
Switch to the Team Synchronizing Perspective.
Click the little synchronize button in the Synchronize View.
Choose Git
Pick a suitable branch to sync against, like refs/remotes/origin/master
Make sure to check the "Include local uncommitted changes in comparison" box
Click Finish
Now, change some files and watch them appear in the Synchronize View. Double-click the changed files to see the diff (like in the screenshot below).
Are you aware of the 'Git Staging' view. It keeps track of all the files that have changed and you can review the changes any time. (This can be a bit better than using the commit dialog)
An alternative is to commit all changes without reviewing, and then use the history view to compare two commits (Simply select the last top most commits, right click and select 'Compare with each other'). This way you do not have to keep double clicking individual files. If you need to change something you can always 'Amend' the last commit. (I usually follow this approach)
I am writing this as of Eclipse Oxygen, but it should apply to other versions as well.
Option 1 with team synchronizing view: right click the project > Compare with > Commit. You can choose your latest commit here, even if you haven't pushed it to repository.
Option 2 with diff view: If you want to see the "diff" version without committing, you can achieve this by right clicking your project > team > stashes > Stash Changes > check Include untracked files. This will save all of your changes to a stash. Then you will right click project > team > stashes > select stash you saved. You click the green arrow at the top right to re-apply all of your changes you stashed back to your code. In the same stash window, you will see a "Diff" tab at the bottom right. Clicking on the diff tab will show your changes in the red/green highlighted diff style. I wish there was a way to generate a diff view without stashing, but this is the only work-around I have found.
I'm currently reorganising our TFS source control for a very large set of solutions, and I've done this successfully so far.
I have a problem at the moment where I need to delete a legacy "Release Branch" TFS project that was branched for the old structure, and is no-longer required since I now host a release branch within the new structure.
This is an example of how the source control now looks after moving everything:
$/Source Project
/Trunk
/[Projects]
/Release
/[Projects]
$/Release Branch Project
/[Projects]
/[Other legacy stuff]
So far I've found information that says:
tf delete /lock:checkout /recursive TestMain to delete a branch.
TfsDeleteProject to delete a project
tf delete seems to be only relevant when I need to delete a branch that is within the same project as the trunk, and TfsDeleteProject doesn't seem like it will delete the branch association from the source project (I hope I'm wrong, see below).
Can someone tell me if the above will work, and in what order I should perform them in, to successfully delete the TFS $/Release Branch Project while also deleting the branch association (from right-click $/Source Project -> Properties -> Branches)?
Let me put the facts like this:
Within the context of the TFS source control system, "Delete" is a purely logical operation. You can Undelete at any time. You can have multiple deleted items occupy the same path over time, or even simultaneously. Branch relationships are preserved.
TFS "Destroy" is physical removal. To maintain database integrity, that means all entity relationships are removed too: changeset history, pending change records, shelved versions, merge history, and yes -- branch hierarchy. This Destroy feature was introduced in TFS 2008.
Destroy is the only operation allowed to alter the merge history table (from which branch relationships are determined). All other operations are strictly append-only.
TfsDeleteProject does its best to completely remove all traces of a project, the primary goal being to allow creation of a brand new project with the same name. Some TFS subsystems support physical deletes; some, such as WIT field metadata, only support logical deletes, even in TFS 2008 & beyond. In the case of source control, TfsDeleteProject invokes "delete" in 2005 and "destroy" in 2008+.
In TFS you generally cannot permanently delete anything inside a team project (and TfsDeleteProject deletes a complete team project, but it is not clear if the source control content will actually be removed as a team project is just the top level of the source control tree).
A delete of a file, or whole set of files is just another tracked change, go back into history and it can still be seen.
You could use permissions to make it inaccessible to all. Or rename under an "Obsolete" team project.
EDIT (I finally remembered where this command was):
There is another option, from the command line: tf destroy:
Destroys, or permanently deletes, version-controlled files from Team Foundation version control.
I would expect this to remove the branch records to create the, now destroyed, files... but you might need to check.
Select the branch folder you want to unbranch. then
File > Source Control > Branching and Merging > Convert to Folder.
In VS2013 I couldn't find it under #Radhika answer
I did find it under Team Explorer > Source Control Explorer >right mouse on project > Branching and Merging > Convert to folder
Hope this saves you time.
Edit Copied from comment by #DdW: you need to do a Get Latest Version after converting, before the Delete option will be enabled
REMOVE A BRANCH USING ROLLBACK
Right click on the select branch.
Select rollback to specific changeset.
Enter 1
set.
Choose 1.
The branch will be marked for deletion.
Check in the changes and it will be removed from source control.