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.
Related
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.
I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).
But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?
The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).
Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?
Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?
The term you are looking for is "commit".
Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.
Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.
Three things about SVN you should know:
Trunk - The main version of your code
Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.
Each project in your repository should have 3 folders in it:
/trunk
/branches
/tags
These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.
Terminology
Working Copy - The copy on your hard-drive, that contains all your edits, etc...
Add - Registers a file for tracking in version control
Update - Updates the working copy with changes from the server repository
Commit - Updates the server repository with changes from the working copy
Switch - Replaces the working copy with another folder within the server repository
Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
Patch - A set of differences that can be used to update a file.
You commit changes to the repository
Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.
I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.
What you want to do is 'commit' the changes made to your files to the repository.
You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).
Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.
Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:
Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot
Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)
Cheers
EL
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.
I'm using TFS and trying to merge a branch back to the trunk from which it was made. Trouble is, the Source Control Merge Wizard has no entries in its Target Branch dropdown list.
I suspect this is because the trunk was renamed after the branch was made. Is there a simple way that I can still perform the merge and have TFS recognise that the two branches are actually related?
I know very little about baseless merges, but is this the sort of thing they're used for?
You might have to use the TF command-line utility. There are some features of TFS (even in 2008) that are only available from the command line. See the merge command.
I have not tried this, and TFS under 2005 was not particularly stable IMHO. (It got much better after 2008 and SP1.) I would recommend replicating the scenario (branching, renaming the trunk, merging from the command line) in a test environment or on a non-critical branch first.
I also haven't tried baseless merges. This article makes it sound similar to what you're doing, but also says that you have to use the TF command. I would think (hope) that there would still be a relationship between the branches after you renamed the trunk, though.
We have two different projects on our source safe database (one of them is a copy of another one for some reasons there was a problem with our branching operation that didn't pin our branched files therefore I had to get a label and add it as a different project)
I know how I can see the differences between two projects and I know that there is a mechanism that let us merge differences into one file (I think "reconcile all" will do the trick but i am not sure)
So here's my question how can I merge a file in a project with another file from another project?
VSS (or as i call it, source destruction system) will destroy your code if you try to merge it using the built-in tools. Why does it do that ? .. because its a lame tool.
This is what i recommend
Get latest both branches.
Get the last version of the code
before you branched. (just see the
date and guess if you have to)
Do a 3-way merge because you have a
base.
add the merged files into subversion
(or something better than
sourcesafe).
I have many old projects stored in sourcesafe. Its hopeless trying to use the built-in tools to do anything other than get latest, checkin and checkout.
Checkout the latest version of the first VSS somewhere.
Create a repository using a different VCS tool (Subversion should be the most simple choice).
Import the project version into the new Subversion repo as a branch.
Checkout the latest version of the second VSS somewhere else.
Import the project version into the new Subversion repo in a different branch.
Use any Subversion tools to merge the two branches.