What will happen if Developer A checks out a shelved file, make some changes and check it back in.
Meanwhile, Developer 'B' is looking at the shelved set and he decides to work on the same file which is now updated & checked-in by Developer 'A'.
Will TFS pull up the Merge change screen or will it allow Developer B to access the originally shelved file?
It depends on the workspace version of developer B. If developer B is on the version from which the shelf-set was created, he'll be able to work in the file with no interruptions.
If he's on a newer version and when there have been changes to the file since the shelf-set was created, he'll be asked to merge.
If he's on the version after A checks in the changes to the shelved file, he'll likely be prompted to merge the changes, or when the changes are in tune with the workspace, will just be able to unshelve the changes without being pompted.
In general it's better when two developers don't work on the same shelveset, in such case it's better to create a temporary branch (topic branch/feature branch).
Related
I have shelved my changes in TFS which will be checked in few days time. Now i want to work on different TFS card which belongs to same file. How can i work on the same file when its changes are not checked in yet ?
How can i work on the same file when its changes are not checked in yet ?
You should use Branch. You can create a new branch based on file are not checked in, then you work on different TFS card with previous branch, after that, you can check out the new branch to work on the same file when its changes are not checked in.
Shelvesets are per-user and differently stored in the source control - it is not possible to merge shelvesets, there's no history etc. The only action possible is unshelving; you cannot even merge files while doing so. So, we only use it as a temporary storage for things that are not finished yet and thus cannot be checked into a branch.
So, you should use branches. Maybe a Main branch and different development branches for features & bug fix.
Hope this helps.
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.
I pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.
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.