When I run the command tf workspaces /collection:TeamProjectCollectionUrl, I see that I have three workspaces named Apple, Banana, and Cherry on my local computer.
I change my current directory to the folder that contains the folders for these workspaces, and I run the command tf merge /candidate Apple Banana.
However, I receive the error message Exactly two items (source and target) are required. Either local or server paths may be used. So I run the merge command again, but this time I specify the full paths to the folders for Apple and Banana respectively. Again, I see the same error message.
What am I doing wrong? How can I merge Apple into Banana through the command line?
The tf merge command is not used to merge 2 workspaces, it is used to merge 2 branches in TFS. To know more about TFS Branch and Merge, please refer to this document.
If you want to merge/combine 2 workspaces (from Apple to Banana), maybe you could follow these steps:
In Visual Studio, switch to Apple workspace first , check in all changes under Apple.
Then switch to Banana workspace, Right-click team project and choose Get Latest Version. Then you will get all changes just submitted from Apple.
If you edit the same files in Apple and Banana, you may get conflicts now. Just use the Merge tool to merge the conflicts.
After you solve the conflicts, the Apple are merged into Banana.
Related
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.
There are a lot of great open-source projects on github. Most of them come with great sample apps.
Now I go through the following steps to get a repository:
Visit a github repository, e.g. https://github.com/omz/AppSales-Mobile
Click Clone in Mac to clone the project
Open GitHub app in Macbook
Right-click AppSales and select Show in Finder
Open the xcodeproj in Xcode
Modify Bundle identifier in ...-Info.plist file
Modify Code Signing Identity in the target
Compile and run
Whenever there is any update in the repository, I open the Github app and discard changes made in step 6 to 7 above, and sync. Then go though step 6 to 8.
By using the Github app, how can I keep the changes made in step 6 to 7 and also get new updates also?
Use a git client and most of the repetitive tasks you are doing now will just ... go away. Tower is a good choice, but you can always use the command line as well:
git clone https://github.com/omz/AppSales-Mobile.git
cd AppSales-Mobile/
open -a XCode AppSales.xcodeproj/
Run the project, change files, do whatever. Then when ready to get updates from upstream server just do:
git pull (or git fetch, then git merge).
Alternatively you could add the files you are changing to your .gitignore file, so that they aren't tracked by Git.
What is the best way to checkout two different versions of a project in Eclipse Egit and have them show up in seperate directories?
My situation is as follows. I was working on a project and made some good changes and some bad changes (State A). I want to check out a previous working version of my project (State B) and copy and paste some of the good changes from State A into State B. Every time I try to check anything out it just replaces the files shown in the package explorer.
That's because one Git repository has one working directory, and the working directory reflects all branch changes etc. So if you want two versions, you need two repositories (just clone the one). Since you cannot import two projects with the same name in one Eclipse workspace, you have to rename one project after the checkout and before project importing.
But you could also use the Compare mode. Select the project, choose Compare with -> Branch, Tag or Reference and select the other branch, with which you want to compare. Then you can just add the contents from the other branch to the current files.
What you're asking for is not very git-ish, but here's how you'd do it.
You'd take your existing repository and you'd clone it to a new repo. In that new repo, you'd check out your "to" version (either by branch or tag or commit ID) and in the old one you'd check out the "from" version. Then you'd point Eclipse at the two directories to create projects from them.
Then you've got two projects in Eclipse, each containing a working directory that is the different versions, and you can manually move code from "from" to "to". Once your "to" project is the way you want it, commit that, delete the "from" repo and project, and Bob's your uncle.
The git-ish way of doing this is to use git bisect to find the commit that contained the bad change, and then revert that commit either in whole or in part.
We migrated from a different source control system. The latest files from each branch were checked in to folders in TFS 2010 source control, and we used the "convert to branch" command on each top-level branch folder. Since the initial checkins, work has been done on the trunk and the branches.
However, we can't do merges from the GUI because TFS does not understand the relationships between the branches. The "reparent" command does not offer any options. Is there a way to use tf merge /baseless /discard /recursive to set up the relationships? Will this cause problems since there have been checkins after the initial ones?
I've just spent the last 6 months migrating 100 or so VSS repositories in to TFS so I feel your pain! I've only done this in TFS 2008 but there is no reason why it shouldn't work in 2010.
I would treat a baseless merge as a last resort as you'll be stuck doing merges from the command line.
The trick is to establish the relationship between the branches before you import your code.
(I'll use a simple single dev branch as an example but you should be able to use the same theory regardless of the number of branches)
Create a new team project, create your "trunk" then branch to "dev". You should now have two empty branches.
Import your code in to "trunk" and "dev".
Merge from "trunk" to "dev", you will almost certainly have lots of conflicts, TFS should be clever enough to ignore files and folders that are the same, but not always. You will need to decide which of the conflicting files you want to keep (usually the ones in the "dev" branch but you probably want to have someone who understands the code near at hand to make the decision)
Now you should have 2 branches full of code that have a relationship.
If you have multiple "dev" branches then I think you should always merge from "trunk" to "dev" first, this sets up the relationship and gives you the option of keeping the version of the code in "dev" as this is probably more recent that the version in "trunk"
In your specific case I would follow the above but instead of importing your files (step 2) from the file system, you could branch the code from your "old" team project in to the new one i.e.
branch $/oldTeamProject/Devbranch in to $/NewTeamProject/DevBranch and $/oldTeamProject/Trunk in to $/NewTeamProject/Trunk
then merge $/NewTeamProject/Trunk in to $/NewTeamProject/DevBranch
I've done this a couple of times in TFS 2008 and it works like a charm (except the pain of doing the initial conflict resolution). Having said that I would recommend doing a "test" migration, just to make sure you've covered all of the angles. If this works ok then you can keep the result, if not you should have learnt some lessons for the real migration :-)
If you've renamed any files or folders then TFS won't know to establish the relationship and you'll get duplication in your "dev" branch after the merge. You'll have the same issue if you do a baseless merge at the folder level. There isn't an easy way around this I'm afraid. you just need to keep an eye out for anything that look slike it's been renamed and manually resolve them after the merge.
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.