I'm new at TFS in Visual Studio and I want to understand something about Shelve and Undo.
Let guess I checked out some files, made some changes and then shelved them.
In that moment - the source code which was before I made changes is restore to original code so all the team members won't see my changes?
-- or --
they see the modified code until I Undo pending changes?
And if I undo the changes - will it affect my shelvset?
So you need to understand what is actually happening. When you make changes, they only exists on your machine until you check them in to the repository.
A shelveset provides a "safe" place for you to store your changes before you check them in.
The rest of the team won't see your changes until you check them in to the repository. So when you undo changes it is merely the changes that you made to your code that is on your machine.
In your example above, your team won't see any changes until you actually check it in.
Changes in Shelvesets can be seen by the other team members, but they are not committed to the repository. They would have to go to Pending Changes -> Actions -> Find Shelveset and type you name in the user search box.
Only when you do a check-in, will others see your changes in the repository.
Undo will remove the changes locally, but the shelveset will remain so that you or anyone on the team can get the changes back locally.
Related
I am using TFS recently. I am developing an electron application. So while running my application, I am stori ng some data in my local workspace files . But I want to store this globally so that every others can also access it even before it is checked in. Something need to behave as global cache in TFS. So is there any solution for global caching in TFS?
It seems you have pending changes that are not ready for check in but you need to share them with another team member. If this is the case, you can create a shelveset by follow the steps below:
In the Pending Changes page of Team Explorer, make sure that the changes you want to shelve are listed in the Included Changes section.
Choose the Shelve link.
Type a name for the shelveset and choose the Shelve button.
Then other team members can find a shelveset and work with it.
I work on a project that has a series of configuration files. From time to time, these files need to be updated with new properties or settings, or we update how content is stored in some of these fields. This means that we need to update these files to our project source control since we need to push these changes to all of the devs on this project, when these changes occur.
However, 95% of the time we want to ignore the changes in our local configs because they contain data-specific changes that are specific to a particular developer or his machine.
What I'd like to do within TFS is choose whether to commit the changes in these configuration files, or not, with each upload. Preferably, I'd never commit my personal changes (as they relate to my personal, localized data.) However, if I unstage this work, I can't switch branches until the changes are committed. If I undo the work, it's quite a pain to switch branches and then manually recreate all of those personal changes.
Is there away in TFS to store a set of changes, and when I update or switch my local branch, re-apply the changes to my local working set? Also, I don't need TFS to ignore these file-changes. Sometimes I do need to upload changes, especially when we're adding new config keys or changing the structure of the data. In such a case, I push up my file and everyone else will see the change in structure. However, if we can all apply localized patches to the specific regions/portions of the files with our user-specific code, it will save us a lot of time in re-integrating these files into our local, working projects. Can this be done?
According to your description, you could use shelvesets to handle the situation.
Since some of the pending changes that are not ready for check in, you could suspend your work and work on a different task/branch.
You can move your pending changes to a shelveset on the server and then clean your workspace. The shelveset saves and stores not only your file revisions, but also the Comment, the list of Related Work Items, and check-in notes (if you evaluate policies before shelving).
After the work have done, you could resume the shelveset to pending changes, unsheveset to local and keep working on it.
You could do this either from VS IDE or tf command line, more details please refer this tutorial: Suspend your work and manage your shelvesets
I work in Visual Studio on C# project.
I edit some files it that project simultaneously. After some work is done i want to divide all changes to "groups" of changes and commit each group changes to separate commit. Its okay when it comes to files - i include one files, exclude others and all is fine.
But problem appears when some changes are in the single common text file. I'd like to split them to different check-ins by TFS itslf, but as far as i know it is not possible.
So tell me please, is there any way to split changes to distinguish them due development process? For example when i start editing common file i press something button or issue a command. Later, when i have to add changes regarding to another check-in to that file, before these changes are really done, i press another button (another command) and since this moment changes are recording as needed to be commited to another check-in.
I hope you understand what i mean. Sorry for my bad English.
If you are going to make a quick change to a file that has work in progress, you should shelve the changes and revert to the source control version (uncheck the "preserve pending changes" box). Then you can make the changes and check in the file. After that, unshelve your changes (your work in progress) from earlier, VS will merge the changes with your checking and you can carry on.
Since it sounds like you have already made the changes and the file contains code you are ready to check in and code you don't, one thing you can do is to shelve the changes now (but do "preserve pending changes"). Then you can delete any code that aren't ready and check in the file. After check in, you can unshelve your changes.
You might want to consider using branches to isolate your long-running changes; although that has its own set of problems.
You could create another workspace on your computer, and use each workspace for a different task. That way, you can work simultaneously on different tasks on the same file without affecting each-other. When you check-in from one workspace, do a "get latest" on the other workspace and merge the changes there before you check-in the other work.
We are using TFS 2010 with gated checkins. I've got some question about what I think is strange behaviour. Look at the following process:
File A is checked out by me exclusively.
File A is changed
File A is checked in
TFS asks to build changes
Build started
File A is reverted locally to the old version
Build succeeded
Asks for reconcile -> however during reconcile there are no changes to be made
After clicking OK, the File A is checked in with my changes, however my local file is still the old version.
Why does it have this behaviour? This does not seem logical to me. It seems logical until step 8. There it should get the latest version of File A for my local repository. Is this a setting somewhere?
It is my understanding, that Reconcile works by looking at files checked in for the build (shelved, actually), check if the file in your workspace has pending changes, and matches the built version. If they don't match, (ie. you edited in between) it will ask you to merge. If they do match, it will perform an undo, and getting the latest version (which will be the same content, since the TFS server has just checked your changes in).
In other words, if you do not choose to preserve pending changes locally, reconcile won't work and you need to do a get latest manually to get your most recent changes back into your workspace.
Shelving
What happens is that, when you check in, your changes are added to a shelve set. In other words, your changes are shelved. When shelving changes you can choose to roll back your local changes.
For instance when you are working on a problem and suddenly you need to fix another problem with higher priority. Then you can shelve your changes (of the problem you're working on) and roll those changes back locally. This allows you to work on the new problem and check its changes in when you're done. Once finished you can unshelve your previous work (of the first problem) and continue your work.
Gated check-ins
With gated check-ins, shelve sets are created automatically. When shelving you have the option whether your local changes are kept or not. I.o.w. you can shelve changes without rolling them back locally. So when the "Keep local changes" checkbox is not checked you will have this strange behaviour (I also find it very unintuitive).
Locks and 'Preserve local changes' option
The "Preserve local changes" checkbox is disabled however if any of the files in your workspace are locked. Even if they have nothing to do with your changes (also not very intuitive i.m.h.o.). Locks can be put manually on files or automatically in the case of exclusive lockouts (disable "Allow multiple checkouts" checkbox in the projects build configuration). So if you have exclusive lockout and someone modifies a file then it becomes locked and therefore you cannot use the "Preserve local changes" option.
Workaround
To workaround this problem I think you can choose one of several poisons:
Do not use gated checkins
Do not use locking and therefore do not use exclusive lockouts
Do not use colleagues
Learn to wait for the build to finish and always perform Get Latest Version (Reconcile will not do that because it will only do that for files you have modified in the mean time) or make sure that you automatically GLV when editing a file.
Do not use TFS :-)
Hope this helps.
Furthermore, if the gated checkin build failes, shelveset files remains as checked-out by build service account. We found a way to undo checked-out files but reconcile doesn't work becuase "Preserve pending changes locally" is greyed out if "exclusive checkouts" is enabled on team project.
I'm using Visual Studio 2010 Pro against Team Server 2010 and I had my project opened (apparently) as a solution from the repo, but I should've opened it as "web site". I found this out during compile, so I went to shelve my new changes and deleted the project from my local disk, then opened the project again from source (this time as web site) and now I can't unshelve my files.
Is there any way to work around this? Did I blow something up? Do I need to do maintenance at the server?
I found this question on SO #2332685 but I don't know what cache files he's talking about (I'm on XP :\ )
EDIT: Found this link after posting the question, sorry for the delay in researching, still didn't fix my problem
Of course I can't find an error code for TF203015 anywhere, so no resolution either (hence my inclusion of the number in the title, yeah?)
EDIT:
I should probably mention that these files were never checked in in the first place. Does that matter? Can you shelve an unchecked item? Is that what I did wrong?
EDIT:
WHAP - FOUND IT!!! Use "Undo" on the items that don't exist because they show up in pending changes as checkins.
I had deleted the files in trying to reload the workspace, even though I had shelved the changes. Then VS2010 thought those files were still pending to save. I didn't need that, so I had to figure out to "undo" the changes in Pending Changes.
Then I could unshelve.
It thought I had two ops (unshelve, commit-for-add) going simultaneously, and I thought I had only one op (unshelve).
This is a slight aside to the OP's question
You can get a TF203015 when you try and batch merge a multiple changesets from one branch to the other without due care.
Consider a situation where you have a MAIN trunk and a DEV branch. You branched DEV from MAIN and have diligently worked away at a feature in DEV; checking work back into DEV as you progressed. Now fast forward a week or two. You are now feature complete and want to merge back into MAIN.
This is where one of our devs hit this error.
He had been working on one solution for weeks, and checking changesets back into DEV periodically, so wanted to merge a non contiguous series of changesets back into MAIN.
So he picks the merge option, selects the first changeset; merges without issue, then immediately went to merge the next changeset; and bang TF203015, and its very unhelpful test in the output window; incompatible pending changes.
After a little fiddling around we now realize what is going on here; the first merge created a pending change in MAIN for the developers solution. The next merge attempt was also changes to the same solution, which would require TFS to "queue up" a second set of pending changes to the same files. It cant do this.
So in this scenario TF203015 means; "The destination branch already has pending changes on some files that are changed in this changeset. Please resolve and commit the destination branch changes before performing this merge operation"
The solution; after each merge operation our developer tests the workspace for MAIN and commits the pending change caused by the merge, then goes back to DEV and repeats.
Actually sensible and simple, but masked by a very obtuse error message.
You can use the Team Foundation Server Power Tools March 2011 (http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx) that includes the command tfpt unshelve.
Once the Power Tools are installed, open a Visual Studio command prompt, change to the directory that contains the project of interest, and execute the tfpt unshelve command. It will unshelve and display the merge dialog so you can resolve the conflicts.
I credit this blog post with helping me find this solution: http://fluentbytes.com/the-how-and-why-behind-tf203015-file-has-an-incompatible-change-while-unshelving-a-shelve-set
I had what appeared to be the same issue but I had created a branch after shelving my changes and I wanted to unshelve those changes to the new branch.
TFS cannot unshelve to a different path than the path upon which the shelf was created.
Solution: I unshelved back to the original branch then I used beyond compare to merge the changes from my original branch to the new branch and checked in.
It could also be that after you create a folder in say a "Test" and you want to merge from dev to test, that you do not have that newly created folder structure checked into TFS - You will /can also get this error message.
Thus this message error CAN occur without anything to do with SHELVESETS as well for others coming from google and finding this page.
This might be the same as jcolebrand's answer, but I'm afraid I found the phrasing there a bit abstruse. Sincere apologies if I'm just repeating.
In my scenario the incompatible pending change message was presented because I was trying to roll back multiple changesets, and the same file was affected by more than one of those changeset.
In my case I did not want to commit until all the changes had been rolled back. I believe if I had been able to commit after rolling back each changeset, the error would not have happened.
The method which worked for me was as follows:
I opted to roll back one changeset at a time. I found using the command line was actually a more informative way of doing this because it lists all the conflicts, whereas I think the VS UI rollback just lists the first.
While rolling back a changeset, if there was an incompatible pending change, I had to undo my workspace's pending changes for the affected files.
When all the changesets had been rolled back, I had to manually revert the files which had experienced incompatible pending change. Mostly this could be achieved simply by getting a specific version of the file (the "last-known-good" version before all the bad checkins started). But for some files where there had been both desired changes and undesired changes, I got the "last-known-good" and manually applied the good changes to it.
This link resolved my issue:
https://blogs.infosupport.com/the-how-and-why-behind-tf203015-lt-file-gt-has-an-incompatible-change-while-unshelving-a-shelve-set/
The reason was pending change in the same work space create an incompatible change. So undo the pending changes and try unshelve. This should resolve the issue.
If you have two branches MAIN(target) and DEV(source), now you want merge DEV into MAIN, then all files you want merge from your source, must not be older then the similar files in your target branch.
For example: you have an changed file test.cs in your DEV branch, changed at 14.03.2016. In your MAIN branch you have test.cs changed at 15.03.2016. So the target is newer then the source file and you have TF203015.
Solution: navigate in TFS Explorer to the conflict-file and merge it explicit. TFS will open the conflict manager and you can merge the conflicts by hand. Following you can merge the selected changeset.
Remarks: If you have more conflicts, you must navigate to each conflict-file and merge it explicit, so TFS opens the the conflict Manager and you can merge it by hand.