I'm going to create a new (vc)project which will start as a copy of another project.
I want to have the possibility to simply merge changes between these two projects, although they are inside another big branch.
I want to do this by branching, but when I do branch from ui, the branch is created and immediately checked-in. I don't want to do this.
Is it possible to make pending change of type "branch" without checking-in?
Branches are created on the serverside so they are automatically checked in. I would recommend using 2 shelvesets and setting up a secondary workspace where you can merge the two shelvesets.
Related
My team's policy is to not check in broken code into TFS. But what if two team members are working on the same file and each member's work represents a partial solution ? One members changes won't work without the other.
How is the best way to combine the code and still follow policy of not checking in broken code ?
Both developers could create a shelveset of their changes once their own coding is complete. Once it's time to merge their code, you have 1 developer unshelve the other developer's shelveset into their own workspace. Doing this will also trigger the Merge Tool in case there are any merge conflicts that can't be automatically resolved. This should allow the developer to combine work with the other without checking in broken code.
Note that both developers should make a shevleset of their own work before unshelving the other's, in case the unshelve of the other developers work goes terribly wrong in the merge and they need to revert their own work to the un-merged state.
Here's some documentation on creating and unshelving shelvesets
Consider allowing broken code on branches. The team members could commit code to branches and merge those branches together before merging into master. Your primary or master branch should require a passing build before a pull request can be merged in.
Look at the feature branch model: https://learn.microsoft.com/en-us/vsts/git/concepts/git-branching-guidance. This does not depend on Git but it is convenient as branching is cheap.
Both developers work on the feature branch which is allowed to be broken. When they are finished they issue a pull request to the master branch. The merge is only allowed if all tests pass to make sure the master branch stays healthy.
We've had this happen more than a few times were we consider it to be more than a fluke at this point. When we are merging back after we are complete with our branch there are way more changes then their should be. So most of the files showing as pending changes never changed (in most of the cases in neither the branch or the base). When i compare them (i use beyond compare) there are no differences. I haven't went through all the files that didn't change but in most cases it seems like they are marked as [merge] and the files that actually changed are marked as [merge,edit].
In one case we probably changed around a 100 files it pending changes showed more than 22,000 changes. We tried checking them in at one point thinking tfs would be smart enough to know what files changed and which didn't. But it checked in all files. Does anyone know whats going on and how to fix it?
We are running TFS 2012 w\ Update1
Everyone is using Visual Studio 2012 w\ Update 1.
For anyone having the same issue a work around is to undo your pending changes. When you get the confirmation dialog choose "No to all". Only your pending changes should be left.
Regarding the problem where you had changed 100 files and TFS wanted to merge several thousand. This is usually caused by renaming (or deleting and then un-deleting, or moving) a branch. This has bitten me a couple of times and I feel your pain.
The best advise I can give is, once you've created a branch, leave it alone. Don't move it, don't rename it. If the location or name of the branch are wrong, live with it until it's time to delete the branch and create a new one.
Because of the way TFS 201x work behind the scenes, changing the root folder of a branch effectively turns it in to a different object. When you try to merge the branch again, TFS will perform a baseless merge which effectively means that it appears that all files in the branch have changed (even though they haven't) This is new behaviour, older versions of TFS (2005 / 2008) don't suffer from this problem.
e.g. you have a Team Project that looks like this
$/TeamProject/Main
You then create a branch from "Main" called "Dev"
$/TeamProject/Dev
You can merge as much as you like and there shouldn't be any problems. Then you decide that the folder structure might get a bit messy when you have several dev branches so you create a folder called "Development" at the root of the team project and move the dev branch in to this folder
$/TeamProject/Development/Dev
OK now behind the scenes the move is a rename and a delete, the old dev branch still exists under $/TeamProject/Dev (you can see this by going to "tools", "options", "Source Control", "Team Foundation Server" and then check the setting that says "show deleted items in Source Control"
The folder called $/TeamProject/Development/Dev is actually a brand new thing! Therefore it doesn't have a merge relationship with "Main". Confusingly though the IDE will show a relationship, but really it doesn't exist. The first time you merge from $/TeamProject/Development/Devto $/TeamProject/Main TFS will perform a sneaky baseless merge to establish the branching relationship.
The same thing happens if you rename a branch (the old branch will be deleted and a new branch will be created under the covers)
This Blog goes in to some more detail
The comment above with the "No to all" option in the undo confirmation dialog works okay, but as commented by Mark Hosang, this will not work right if you have new files. Mladen Mihajlovic is right that you can make sure to not select those new files. However with a large code base, wading through this is very tedious.
So my method: before getting to the confirmation dialog, you are presented with a window to select which files to undo. This window has sortable columns. You can sort by the Change column and select only the files with merge status (these are the unchanged files; merge, edit are edited files and merge, branch are new files). Just click Undo Changes with just those selected, and then enjoy the beauty of an uncluttered merge changeset.
Try this:
select all pending files
on context menu click 'Undo...'
in the 'Undo Pending Changes' dialog sort files by 'Change' column
deselect all files except 'merge' using shift+click
click button 'Undo Changes'
From my experience this happens when TFS has no relationship between file A in branch A and file B in branch B.
When merging branches TFS always creates a relationship between the files when no relationship is present already. Hence it wants to check in as "merge" to remember these relationships.
I tend to undo these "merge" changes when i don't need the relationships (e.g. for reparenting).
I have following situation:
I have created some new projects in solution in one development branch in TFS
I'm now merging them into the main branch.
Architect has idea to merge two new modules into one.
I have moved the code files
Project files has already been changed within the merge.
These files have pending changes in form merge, branch, edit. I wan't to make this file merge, branch, delete but TFS won't do that because the file has pending changes. Is it possible to force the deletion or undo edit without undoing merge, branch?
I don't want to try the merge again and combine files from two shelvesets... Is there any possibility to modify the status of pending changes?
No, TFS does not support that.
You could "undo" the file and just pend a delete instead.
As best practice you shouldn't be making changes as part of a merge, you should just do the minimum possible to resolve the conflicts and get it to build (or not even that sometimes) and then make your required changes in a subsequent check-in. This makes it easier to see in the version control history what changes were made when - I very rarely look to see if a merge of a change is any different from a prior edit.
I have created a basic admin system using RoR. It has very basic functionality such as users, roles, security features and a basic UI. I want to put this project into a master GIT repository.
If I want to create future projects, I'd like to use this base project as the foundation. Do I create braches?
MASTER PROJECT
MASTER PROJECT > SUB PROJECT #1
MASTER PROJECT > SUB PROJECT #2
So both sub projects are identical to the master project at this point. If I want to make a universal code change to any file within the MASTER PROJECT, how do I make that change trickle down to all sub projects. That is my FIRST QUESTION.
SECOND QUESTION:
What if I want to make a code change to a particular file on one of the sub projects?
e.g.: If I customize the layout in SUB PROJECT #2 (application.html.erb), I want that change only to affect SUB PROJECT #2. I want all sub projects to use the application.html.erb from MASTER PROJECT UNLESS it has changed (customized). It would be nice if SUB PROJECT #2 only contained the one customized file. All other missing files fallback on MASTER PROJECT.
THIRD QUESTION:
If I make a change to application.html.erb in the MASTER PROJECT, it is supposed to tickle that change down to all sub projects UNLESS one of the sub projects has a customized change to that file already. In this case, SUB PROJECT #2 does.
I'd want GIT to either:
a) Skip the update on application.html.erb on SUB PROJECT #2
OR
b) Prompt a warning to allow for some sort of merge.
Does that make sense? Is this setup possible? What would it be called? Where do i start?
Question 1:
You could use branches to track this. However, you should also consider whether what you need is simply a set of templates.
Git does not perform automatic merges by itself. You can write a script to do this, but otherwise you'll need to manually perform a git merge on each subproject branch.
Question 2:
Any branch you create will initially be identical to the original branch (master), at the time you created the branch. It will not change until you commit changes or merge in changes from the master branch. It wouldn't make sense to have this branch contain only the one customized file, so you may want to consider why you're asking for that if you want to use version control branches. The branch may only contain modifications to the one file, but nothing enforces this.
Question 3:
This is what git is designed for. When you do a git merge on the subproject branch, git will try to automatically merge the content and if it fails it will mark a conflict and allow you to manually perform a merge. You can also tell git to use another merge strategy, such as 'keep the local version', but this is a more advanced technique, and probably isn't what you want.
I recommend you start with the git-tutorial and make sure you have a good understanding of branching in git. Then, revisit this idea and make sure it still makes sense for what you're trying to acheive.
Maybe it's the right choice to put your master project into its own repository and make a new one for each project. There's git submodule which enables you to integrate other repositories in a project. YOu should try to have project specific changes only in the relating repositories, changes on the master project you can update via git submodule!
The team I recently joined has the following TFS branch structure (abstracted):
Main
Foo branched from Main
Bar branched from Foo
I need to blow away Bar and essentially re-branch it directly from Main, rather than from Foo. I do not need to maintain the existing revision history in Bar.
The seemingly logicial and simple thing to do would be to simply delete Bar and re-create it as a branch from Main, however I ran across a blog post from one of the TFS MVPs indicating that deleting/re-creating a branch using the same name is bad ju-ju.
So... what should I do? Is there a way to re-target a branch without deleting it? It's worth noting that the name of the Bar branch needs to stay the same, for various reasons.
Re-targeting branches is not easily done in TFS. I think branching and merging is very, very limited in TFS compared to other VCS-es.
We have on several occations done what you are describing, without noticing any problems. However, I cannot guarantee that you will avoid the problems. Is moving to another TFS project an option? Then you can merge Main to the new project, and branch out a new "Bar" there?
Probably not an option...
You have a couple of options, if you want to keep bar, but change it's relationship with main you could reparent the branch. First you need to do a baseless merge from main to bar
Tf merge /baseless $/teamproject/main $/teamproject/bar
Check in the pending changes.
Once the main and bar branches have a merge relationship you can reparent the branch in source control explorer. Right click on bar, select "branching and merging" and then "reparent". You should now be able to select main. See this blog for more information.
If the history isn't important then you could "destroy" the branch rather than deleting it. This should avoid the issues described in the blog you mentioned. Use the "tf destroy $/teamproject/bar" command line.
As the name suggests destroy is permanent so use with extreme care, once you've destroyed the branch then you shouldn't have any problems re-branching.