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 am using subclipse plugin in Eclipse to use SVN repo. for commit the source changes i use [Right click -> Team -> Commit]
I need to pull the latest changes from SVN repo. i am seeing options for updating the source
Right click -> Team -> Update to Head &
Right click -> Team -> Update to Version
Which one i have to use to update the latest changes in my local repo and what is the difference between them. Please suggest.
The difference is following:
Update to HEAD will do svn update.
In other words it will update your working copy to the last revision from the repository.
Synchronize with Repository is something similar to svn status -u, but even more.
It will open a Synchronize tab (or perspective) that displays overview of your local (outgoing) modifications versus repository (incoming) modifications.
In this tab or perspective, you can review and synchronize (commit / update) individual files, see differences between your working copy files and incoming files from repository, browse commits history, resolve conflicts.
Update to Revision:
The standard Update command has no options and just updates your working copy to the HEAD revision of the repository, which is the most common use case. If you want more control over the update process, you should use TortoiseSVN → Update to Revision... instead. This allows you to update your working copy to a specific revision, not only to the most recent one. Suppose your working copy is at revision 100, but you want it to reflect the state which it had in revision 50 - then simply update to revision 50
Update to Revision can occasionally be useful to see what your project looked like at some earlier point in its history. But in general, updating individual files to an earlier revision is not a good idea as it leaves your working copy in an inconsistent state. If the file you are updating has changed name, you may even find that the file just disappears from your working copy because no file of that name existed in the earlier revision. You should also note that the item will show a normal green overlay, so it is indistinguishable from files which are up-to-date.
In general, I highly recommend you to check out the SVN Handbook. At least first two chapters.
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.
Specifically:
Why do I need to explicitly enable "Enable baseless merges" all the time? I am integrating from my branch to the trunk.
What does "Enable integrate over
deleted targets" mean? Shouldn't it
do this by default? If the file
doesn't exist, and you integrate to
that branch with the file, it should
create the file, right??
What does "Do not get latest revision
of selected files" have to do with
integrating? I should be choosing a
source revision, and a target (to
create a new target revision).
What does "Disregard indirect
integration history" mean? I've never used it, since it sounds scary.
I would be grateful to know, as I am a little unsure of what options to enable when I am trying to do various integration tasks from our trunk to various branches or vice versa. (I am not the buildmaster, but hey, I want to know what he knows).
Why do I need to explicitly enable
"Enable baseless merges" all the time?
I am integrating from my branch to the
trunk.
Can't help you here. Something is not right.
What does "Enable integrate over
deleted targets" mean?
If the target file has been deleted and the source file has changed, will re-branch the source file on top of the target file. Without this option, a file on the branch, that has been changed on the branch and deleted on the trunk, would not be allowed to be integrated back into the trunk.
Shouldn't it do this by default?
Not if you are integrating a file back into the trunk, which you branched from the trunk, then deleted on the trunk. Normally 'p4 integrate' avoids mixing outstanding edits with a deleted file. You have to use the advanced options to tell it how to deal with a deleted file.
If the file doesn't exist, and you
integrate to that branch with the
file, it should create the file,
right?
When integrating a file, that previously never existed (i.e., it was added to the branch), from one location to another, yes, Perforce will simply create it in the location into which you are integrating. However, if the file originally came from the trunk, was deleted on the trunk, and now you're trying to integrate it back into the trunk from the branch, you have to tell it what to do via these integration options. Here's the command line switches to which these options correspond:
Enable integrations around deleted revisions = -d
Integrate over deleted targets = -Dt
Delete target file when source is deleted = -Ds
Try to integrate changes when source is deleted and re-added = -Di
You can learn more about them in the integrate command help (type "p4 help integrate" at the command line).
What does "Do not get latest revision
of selected files" have to do with
integrating?
This tells Perforce to use the workspace revision of the target file. By default, the head revision of the target file is automatically retrieved into the workspace before integrating. Say you have made one revision to a branch file and integrated it back into the trunk. The trunk and branch now have two revisions of this file. You submit a change to the branch file so it now has 3 revisions. You sync the branch file back to revision 2. If you were to do a normal integration right now, Perforce would assume you want to integrate everything up to the head revision and would integrate revision 3 of the branch file into the trunk. If you were to select this option, it would say, "all revision(s) already integrated" because you have revision 2 in your workspace. It would be the same as attempting to integrate with the "Limit the range of the integration:" option set to "Integrate all revisions up to:" Revision 2.
What does "Disregard indirect
integration history" mean? I've never
used it, since it sounds scary.
I can't figure out, nor find any info about, what this does.
In general, to merge two files, perforce looks for a "base", the closest revision to the two files, and uses that to provide a much better diff than just directly running a diffing the two files. See Knowledge Base Article. Without knowing your perforce setup, I couldn't say what was going wrong, however, p4win has some nice graphical tools to visualize branches, you might be able to determine why perforce can't find a base for you. This is also what "Disregard indirect integration history" does: stops it from looking for the base.
For the "don't sync to head": when integrating, your "target" is the files in your local client, which you aren't specifying a revision for; instead, perforce will either sync your revision head (if you don't use "-h"), or will use the one you currently have. You can't specify an arbitrary revision because your local client only has a particular one.
"Enable integrate over deleted targets" can lead to problems if done blindly. Here's an example: Imagine you refactor your code in your next release branch, and eliminate a source file as a result - the functionality was merged into some other source files. You then fix a bug in that original source file in a maintenance branch for the previous release. If you integrate over delete by default, the dead source file comes back, but it won't be built and the bug wouldn't have been fixed. It'd better to be warned that this occurred so you could manually merge the fix into the other source files.
I deleted a branch in TFS and just found out that I need the changes that were on it.
How do I recover the branch or the changes done on it?
Specifically in Visual Studio go to "Tools-Options" then Select "Source Control-visual Studio Team Founation Server" and check the "Show deleted items in the Source Control explorer".
Having done that - you can then right click a folder and say "Undelete"
As described in the TFS FAQ:
Are Deletes physical or logical? Can accidental deletes be recovered?
Deletes are fully recoverable with the “undelete” operation. You wouldn’t want to do a SQL restore because that would roll back every change to the TFS in the time since the file was deleted.