Our team started using TFS few months back and we are learning as we progress. We first checked in our existing code to TFS thereby creating a Main Branch. We then created a Development Branch from this Main branch.
We just did a release and I merged Development branch with Main. It asked me to map Main branch folder on my workstation. Done that Merge completed successfully. But after merge I noticed on server that change sets are still old and source code on server has not changed.
looking further I noticed that the changed file is marked as 'merge pending'.
When I opened solution from mapped folder of main branch, I did see that all changes from Development branch merged to Main are in pending state.
Questions
Do I always have to check in pending changes after each merge in TFS
Is is possible to merge source code on server instead of from
workstation (All code in development is in Checked in state).
I am using VS2012 (if that matters)
Please advise, especially if I am taking a wrong approach with TFS.
In answer to your questions:
Yes, you always have to check in pending changes. Pending changes are local to your machine, they give you the chance to review the result of the merge locally before they are committed to the server. This is especially important because the merge may result in a conflict that you need to resolve before you can check in.
I don't think that this is possible (although I never researched this specific question). This is, again, because of the possibility of a conflict that needs to be resolved manually. Even if you perform a merge programmatically via the TFS API, the merge will happen locally.
Don't worry, you are doing the right thing. Only one word of warning regarding merges in general: Before you attempt a merge, always make sure that you perform a "get latest" operation on the target branch! The source branch does not need to be up-to-date on your local machine because the merge operation will get the source branch data from the server. But the changes will be merged with whatever version your local target branch files have, so if these are not up-to-date you will get unexpected results.
Related
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
I have the following scenario:
I have a Dev and Stage branch
Code is checked into Dev, and at some point those changesets from Dev are merged into Stage
No direct edits/check-ins happen to stage (beyond the merges from dev)
What I want to do is identify/verify that no new code has been introduced directly into the stage branch which did not originate from a changeset in Dev.
It does not appear possible to secure Stage (from a source control perspective) to only allow check-ins of merges from dev (since all operations appear to be merge,edit after I do the merge), so what I thought I could do is create a TFS Check in policy which attempts to compare the merged changes to their source.
I have created a class which derives from PolicyBase and have over-ridden the Evaluate method. In the Evaluate method, I spin through this.PendingCheckin.PendingChanges.CheckedPendingChanges and check the .IsMerge property and .ServerItem property to see if the item in question is a merge and is destined for my Stage branch.
When I spin through each change however, I don't see a way to track its lineage or access the parent from where it might have originated (ie: the Dev branch version #).
How do I only allow merges, but no direct edits on my Stage branch?
The only way to achieve this in TFVC is for you to take ownership of all merges. If you do the merge then you have the control. Many organizations with these sorts of draconian policies create an automated script that does the merge and rejects if there are any conflicts. That way the developer is forced to pull from Staging to Dev and resolve all conflicts before requesting the merge through a web portal. If the merge is successful it was conducted on a server by a single service account and no coder required permissions to Staging of any sort.
This is however dysfunctional. Either you don't trust your coders, or they are not competent enough to work in your code base.
Another method might be to move to Git in TFS for source control. In Git merges are non-editable and are performed as a single action rather than the merge/edit you get in TFVC.
I have an ASP.NET MVC solution (VS2012) under TFS. Let's say I have the latest version on my hard drive (lets name it version X). I know this version is OK (tested and ready for moving to production but waiting for approval). Now I would like to work on another request on this solution.
My question: how can I preserve actual state of my solution BUT continue to work on this solution. At some point, when I get approbation, I will need to retrieve the version X from TFS and move it to production, then continue to develop my pending request.
How can I proceed? Using labels or branches?
We do this using branches.
The day after our code cut off we cut a new branch from the Trunk. We then work with test to make sure this is stable, all bugs are fixed and merged back to Trunk.
This branch is then owned by the test team and anything that goes into it must be approved by them.
We also have seperate Daily and Buddy builds for this live branch. Test can use this to build the latest from that branch at any time.
Before deployment day the test team then build this live branch to create a package. This package is stable and tested. After this has been done, only exceptional circumstances will allow anything else to go into this designated deployment.
Branching is the answer to this problem.
The best branching guidance I've seen is the "Visual Studio Team Foundation Server Branching and Merging Guide".
It includes everything you need to make a decision on your branching structure, including pictures!
I recommend that you start with either the Basic or Standard branch plans, then see how badly you need something more complex.
Switching to GitHub and can't seem to find information on how to do something I used to do with SVN:
First of al I'm a tester so I never commit changes, but I do need to keep a number of local copies of the project each with a small difference to trunk - staging, production, decreased timer values etc
I used to use CornerStone on Mac (just fwiw/don't have it any more), and a single update from SVN would update all my various local 'dependent projects' (all of them the same, apart from one or two lines, usually in a config file). I'd review the inevitable conflicts and almost always reject them, provided the only difference in the conflicting file was my customisation for test purposes, or if there was something new I'd merge it in and leave my staging environment URLs or whatever as they were.
Can I do this sort of thing efficiently with GitHub? (preferably using GitHub's/Xcode's or some other Mac GUI client?)
I did look at the documentation, but can't seem to find anything on this so any help much appreciated/maybe it's kind of unusual to be pulling changes to lots of almost-identical local projects and always be rejecting certain conflicts.. :)
Of course, the ideal solution is to not have configuration data tracked in the repository, or at least make it possible to override via some untracked file.
However, there's no problem with what you want to do in git. You just locally make multiple clones of your GitHub repository. In each, you can make your changes specific to that local copy, and then commit them. Then, when you want to update from the latest version of GitHub, make sure that you pull with:
git pull --rebase
... which will fetch the latest version from the server, and then try to reapply your commits with local changes on top of them. Unless the same parts of the files that you've committed changes to have also been modified in the new commits on GitHub, you shouldn't even have conflicts to resolve.
If you always pull like this, then the commit graph (history) of your project will always be the same as the remote, but with any of your local changes as the most recent commits on top of the remote history.
(I would hope that the GUI clients that you are using have an option to rebase on pulling new changes. Otherwise you can set this to happen automatically with the config option branch.<name>.rebase, where <name> is the name of your local branch.)
Our company is migrating from VSS to SVN as part of an upgrade from VS2005 to VS2010. I am evaluating the VisualSVN implementation – VisualSVN Server looking after the repository, and using VisualSVN Client inside VS2010. Our work is predominantly Web Application Projects.
I am having real problems merging a branch back to the trunk
Here is the scenario (all SVN actions being performed with the VS2010 VisualSVN plugin):
In a given WAP, I have created a branch from the /trunk called /branches/test and configured it to run under local IIS in VS2010 with the branch held on my HDD away from the repository (which is on a server)
I’ve edited the homepage in /branches/test to add HELLO WORLD to the WAP’s default.aspx and committed it to /branches/test
I can verify through the VisualSVN browser, that the trunk version doesn’t have the HELLO WORLD, but the branch one does
I now switch to the trunk in VS2010 I get a warning “There are changes in the working copy. It is recommended to commit or revert them before switching” – an additional commit just tells me nothing has changed (which is right) so I continue
Now in the trunk, I confirm there is nothing to commit just to be sure
Still in the trunk, I select “Merge…” followed by “Reintegrate a branch”, set the From URL as [path]/branches/test and the Merge Depth as “Working Copy”
I get an error, “Cannot reintegrate into a working copy that has local modifications".
Have I got something fundamentally wrong in my understanding of branching here, is my process flawed along the way or is this a feature of VisualSVN?
Thanks
Sounds like a bug in this VisualSVN client thing. Normal Subversion doesn't behave like this.
I've found the problem - it was versioning the solution file, which wasn't showing in VS 2010 by default. Therefore I did have uncommitted changes on the local working copy which I wasn't aware of (the solution file).
I'm not sure of the best way forward here. Should I exclude the solution file (.sln) or version it? My worry is that if it's excluded and I add a project in a branch and merge back to the trunk, when the next person branches from the trunk will they run into problems (as the solution file in their own working copy will not include the new project)?
(I'm new to StackOverflow - should this be posted as a separate question?)