TFS branch from existing project - c#

In TFS I have branch on my name but when this branch is make its maybe after 2 week and I have a many changes on this project.My questions is how to upload my change project in this branch to can merge MAIN and my project without errors?

You need to check-in your changes to the branch first, then merge the branch back to main via the Source Control Explorer.

The best way to do so is to first check in your changes into your branch (Pending Changes), den commit these changes.
Afterwards you have to Merge with your MAIN branch, but be sure to first review your changes with the branch you are merging with.
https://msdn.microsoft.com/en-us/library/ms181428.aspx
If you encounter errors, this official Microsoft resource will help you to resolve errors that can happen after a 2 week difference.
https://msdn.microsoft.com/en-us/library/ms181432.aspx
Something that you should never forget: Before Merging with the target branch of your desire, GET LATEST
microsoft.com/en-us/library/jj155787(v=vs.120).aspx

Related

Retrieve Team Foundation Server Backup which is not checked in

First, I am new to Team Foundation Server Management system. So here is the story:
We have one solution which has 19 projects in it. The last time the projects were checked in was on 9/12/2016 and have not been checked in since then. Many program changes were made since then and on 5/01/2017 while working on the projects in that solution, I suddenly received a message saying, 'The source code have been changed. DO you want to retrieve the changes?' Options provided:
No
No To All
Yes
Yes To All
Since I am the only developer who was working on those projects and I knew no one else worked on it since past few days, so I selected 'No To All' option and carried on making changes. Later when I tried to build the projects, it popped up several errors and did not rebuild/build projects. After examining the code, the finding was the code part of the projects seems to be up to date (till that moment) but the Form part and the form designers of the projects seemed to be way old and have been mismatched with the code.cs part of the form.
First thing I did was to Get Latest Version (Recursive) but somehow the Visual Studio kept the latest program changes in the code part and pulled the old version of many other projects in the solution.
Is it possible to retrieve latest changes (day before 5/01/2017) of code from my local workspace even if I have not checked in on that day? Any help will be useful.
Thank you in advance.
P.S. I did many changes to the program in the project over 3/01/2017 and 04/01/2017 and have built and rebuilt the projects, all with success.
No it is not possible. TFS relies on you to push changes to it, so if you haven't then all you have left is what is on your local workspace. If you have overwritten your local workspace then changes you made in the last couple of days are gooooooooooone....
This is a lesson for you (we've all done it :). Look to use shelvesets regularly for the work that isn't ready for checking in but you want a copy of it kept.

Can Changesets Be Tampered With in TFS

I've been experiencing some situations where I feel as though what is present in a changeset of mine isn't always representative of what I did.
Example: I incremented a version number in AssemblyInfo.cs through the project properties GUI and in a couple other locations. I then checked in my changes and moved on deploying things.
Come to find out, the AssemblyInfo.cs file had been emptied. I checked on my disk and the file contained binary of all zeros.
This is the most recent event in a series of headscratchingly frustrating changeset issues.
Is it possible for someone to tamper with a changeset without leaving any audit trail, or is it possible that the GUI in Visual Studio is corrupting certain things on me?
When you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to get information about:
•which files were changed
•what the exact changes were
•who changed the files
•what the check-in comment contains
•which work items are associated with the changeset
•which policy warnings appeared
TFS won't tamper changesets if you have a successful checkin. You can try on another client machine to see whether your issue persists.
No, it is not possible to make changes to TFS version controlled files without leaving any audit trail by anyone or GUI.
You are able to check the file's history via right clicking the file in the Source Control Explorer and click "View History". From the listed changesets, you are able to check who submitted the changeset on which date. If you don't want any one specific changeset, you can just rollback it.

Deploying branches and maintaining configs in VS2010 / VSOnline

I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.

When editing Resources.resx file, Resources.Designer.cs fails to update because TFS doesn't check it out

I'm using TFS source control.
When I add a new resource key to my resource file - Resources.resx - and hit save, TFS checks out Resources.resx but doesn't check out Resources.Designer.cs. This causes the update to Resources.Designer.cs to fail with error:
The command you are attempting cannot be completed because the file 'Resources.Designer.cs' that must be modified cannot be changed. If the file is under source control, you may want to check it out; if the file is read-only on disk, you may want to change its attributes.
The error is correct in that the file IS read only and the file IS NOT checked out. I don't want to have to manually check out the designer every time I add/edit a resource key. Does anybody know of a solution or work around to this issue?
Note that I have TFS set up to "check out on save" as opposed to "check out on edit". This is deliberate to reduce the amount of unedited checkouts.
EDIT:
This happens in other file types also. For example, I am using RazorGenerator to create compiled MVC views. The same problem occurs if I try to edit the .cshtml without checking out the .generated.cs first.
UPDATE:
This issue occurs on all (as far as I've seen) files that have an autogenerated code-behind: .resx, .edmx, .aspx, .cshtml (when using RazorGenerator for compiled views), etc. I've decided that it's not worth the pain just for having "on edit: do nothing" set. I've decided to reset this to "on edit: checkout automatically". Thanks to everybody for your input. No thanks to TFS team for this FAIL.
Well, I did not think this counts as an answer so I wrote it in comment.
Checkout on save is only triggering when you save file, it does not trigger when file is autogenerated (autogenerate is not trigger for save which does checkout, as this file is edited by custom tool assigned to resx).
I'm afraid you will not get proper answer (the one which will solve your problem) besides that it is by design, but it may be worth opening a case on connect and ask to change this behavior.
Why do you want to reduce the amout of unedited checkouts? If a file is checked in without changes, TFS notices and it will not show in the checkin history of the file.
You can test this yourself by checking out a single file and immediately checking in. TFS will tell you there where no changes and the checkout is undone.
So maybe consider setting it back to checkout on edit? As mentioned in the other answer, this will solve your problems...
I think this is the problem
Note that I have TFS set up to "check out on save" as opposed to
"check out on edit". This is deliberate to reduce the amount of
unedited checkouts.
To avoid above problem, revert back to default settings. Then download TFS power tools.
Then use this command to revert changes which are checked out but contain no edits
tfpt uu /noget
Update: On changing above setting the issue no longer occurs. For details, refer below discussion in comments.
I have to work with TFS at work. I've seen to many miracles and we've spend a lot of time figuring out where the problem is. TFS is the choice of my company, but it's not my favorite.
TFS (especially when server is slow and you have regular network problems) is a disaster for me as a developer. VS looks for modification only over files in solution, and as you can see not all of them. When you use third party tools (fitnesse for integration tests or custom build steps) wich requires to modify files outside VS - you'll probably get the same error as you have.
But we found a solution. On my machine I use git. We've installed git-tfs.
And all you need to remember is three magic commands
git tfs fetch
git merge remotes/tfs/default
git tfs ct
That's it. You will never break company rules. And at the same time you will be free of that kind of weird problems. We've forgot about that nightmare.
EDIT: Local workspaces in the upcoming TFS 2012 will solve several issues, and TFS 2012 will become closer to SVN, but it will not be DVCS. MS invest in integration with external DVCS - please, welcome - Git-TF.

Using (Ankh) SVN to make two files the same across branches

Unfortunately, I'm not entirely clear on how SVN works...
I have a trunk for my main Visual Studio C# solution, and a branch, for work in development. Now and again, something needs to be changed in both, so that the code is identical. I've had a look at the Merge wizard, but it doesn't seem to describe this issue. It seems to allow me to merge specific revision numbers, which may contain changes to other files, rather than considering the merge on a per-file basis.
How do I do this?
It is possible to run "Merge" command on the file. You need to make sure that "Merge From" value points to the file in the right branch (i.e. to the file that has the changes you want to get). You will notice that the merge wizard will list all the revisions for that file. You can now select revision(s) (which may contain changes to other files) safely since only the changes to your file will be merged into your working copy.
Remember to build/test your working copy after the merge, and then to commit the changes back to repository.
You can also take advantage of the "Merge Tracking" feature (available in SVN 1.5+) by selecting the "all eligible revisions" option.
I recommend to configure AnkhSVN to use an external merge tool (via Tools > Options > Source Control > Subversion User Tools in Visual Studio).
The best way to do this is to make the change in trunk, and merge from trunk to your dev branch.
A more complicated version (that keeps your trunk safe while writing this code) is to create another branch from trunk to represent the common "changes" (a service pack branch). Make the changes and test them in the service pack branch, then merge back up to trunk. Then merge down from trunk into your dev branch.

Categories

Resources