It seems like at completely random, someone's changes will disappear, and the history of the changes will disappear as well. It's almost like the history of a file is tied to the file itself instead of being saved on TFS itself. Anyone know why this would be happening?
Edit: A little more explanation.
As an example scenario...
I work on item A to reorganize a view and then commit the changes via gated check-in, which finished successfully.
A couple days later, a coworker is working in the same area and turns around and asks me if I was still working on the reorganization because it looks like it has for the past random length of time. So I step over and look over their shoulder and sure enough, it is EXACTLY as it was before I started working on it.
Naturally, I pull up the history of the file, and there is no record of my commit whatsoever. It's like I just did the work and commit in my head.
Final Edit:
This appeared today - It appears that TFS is taking it upon itself to determine which version is more important and taking that version without consulting the developer.
Related
I had a work space which consists of last month's version of the solution by mistake I took full latest instead of taking specific version, can I roll back to last month's version without using changeset.
If you didn't shelve or check in your code, you can't. A workspace is local. You should not leave changes uncommitted for a long time -- I generally recommend checking code in at least once a day, preferably much more frequently.
If you're working on a long-running change, use branches to isolate work in progress.
In Visual Studio 2013 Update 3, I accidentally checked in a not-compiling, work-in-progress changeset that I intended to shelve in order for a co-worker to take. I rolled back the change set right away. Bad me.
Is there a way to recover that bad/rolled-back changeset as a Pending Changes so that I (or my co-worker) may continue to work on it? I didn't see anything in the UI and had to manually pull out each file and construct the pending changes by hand. It was only 20 minutes of work to code it originally, so not that big a deal (it was my error) but I'm curious if there was a better way.
As was said in the comments, you can "rollback the rollback". I do it all the time. Just find the rollback changeset in history, and roll that back, and it will get you your half-finished changes into your local workspace, so you can continue working on them and check them in when done.
It seems that Plastic SCM does not track code moved between files (compare with e.g. Git) Am I right, or is there a way how to switch this feature on?
(Disclaimer: I work for Plastic SCM).
As far as I know git is able to track moved fragments of code between files when you run a "git blame", but it doesn't use this information during merge, correct? Git is able to calculate the "moved fragment" between files if it happens on the same commit and that's what it does while processing the 'blame'.
No, Plastic is not able to do that yet, which is a shame because we're already doing some interesting things around the idea:
First we have semantic method history which is able to track the history of a given method even when it has been moved, renamed and modified, but always inside the same file. We have plans to extend this to a repository wide basis, indeed we were about to implement it by the end of last year but we had to postpone it since we got some other highly requested features to work on.
The 'semantic method history' is based on the SemanticMerge tech we've developed. Right now it also works inside the file, but plans are also to come up with SemanticMerge multi-file (we even have a working prototype already). I expect this to be several steps ahead of what other tools can do.
Applying the last two together it wouldn't be hard to do something like 'blame with moved code', which as you pointed is something really great to have. Hopefully we'll release something like this in the coming months.
In order to clean up my project structure, I moved a folder into another (new) folder through the TFS Power Tools Shell-Extension (Rename/Move).
After checking the history at the new place, the move is the only entry. (I tried one folder up, down, even on single files in the moved folder.. same result.)
I had also put on some labels on versions of the folder before the move, since there were some important states of the code I wanted to get back to.
So.. what went wrong, and how can I either get the history or at least find out the label names again and check out those versions?
Turns out it is pretty easy.
In Visual Studio 2010, go to Tools->Options. There you can find the option to show "deleted" items (roughly in the middle of the dialog box). The old folder got deleted during the move - it will be displayed again after activating that option. (They will be kind of grayed with a red cross.)
Labels seem to have disappeared, though, so I had to go by version.
In the Source Explorer you have the normal operations again - like View History or Get.
DISCLAIMER: For reference of everyone that gets here, this answer is not fixing #Andreas problem, just giving some context on why this happens and offering a couple of workarounds.
Seems that losing history when moving folders in TFS 2010 is not a bug, is a "feature". (still happening in TFS2012. From this MSDN link you can read official Microsoft answer:
Thanks for the feedback here. The previous comment about this being by design is correct, and there is an option on the command line. In the UI, history of folders is recursive - always. This is because most of the time, users care about the history of the contents of the folder. Files on the other hand dont have the concept of recursive history - you always see the history for the file itself. Now, from the command line, there is an option to show recursive history (/r) and if you run tf history on a folder without the recursive option, you'll see the changes to the folder itself. This would include changes such as a rename for the folder itself.
Workaround to get history once lost: As you can see there, you have a workaround using tf history.
Workaround to avoid losing history: If you want to avoid losing history in folders instead of using move feature, you can use TFS Integration tool to migrate code from one folder to other preserving history, migrating from $/TFSCode/FolderA to $/TFSCode/FolderB. It is a little bit overkill but if the history is pretty important for you is much better than looking for it in deleted folders
It is true that the folder history is lost, but the individual file history is actually not lost. It is hidden under the little "expand me" arrow at the far left on a file history line. Expand it on the oldest history entry for a file, or anywhere you see it, and you will see history of that individual file also from an old location that no longer exists.
At the top of History window you can edit Source location, put the old name and get the full history before it has been moved.
Also, is good to mention that you can get the full history back by moving/rename the branch back to the old location/name.
I'm finding that a number of my changes are being 'lost' when our contractor performs a check-in.
The general process is as follows:
I perform some bug analysis and implement a fix.
I then check-in my code.
The contractor performs a check-out/check-in at a later date.
The changes from the previous changeset (my changes) are lost.
In my view, this is pretty unacceptable, particularly when I'm dealing with application-breaking regressions introduced since the last build.
This has happened at least twice now, and the only thing I can think of is that the contractor is failing to ensure that he has the latest changeset at check-out. Our repo does not allow multiple check-out, and forces get latest on checkout, which makes things so weird (seeing as we both should be working with Server workspaces).
Could there be any other cause of this problem? I don't want to take my concerns to my line manager without being sure I've covered all bases.
Get Latest item on check out is set in the client and not in the repo, which means that your contractor may still be able to checkout the wrong version. They should get merge conflicts upon doing so, but that depends on where they edit (and how they manage such conflicts).
I've seen TFS lose changes this way. I have yesterday gone to a client site, made changes, checked in, today come back to my office, got the changes (assuming it will merge with my local changes like it usually does), gone to check in just now and I can see in the diff that it's wiped out the client-site changes (obviously ignoring the merge locally). I checked in just to confirm what I was seeing and yes there was no resolve conflict needed, TFS thought everything was ok, but my modified local file just blatantly overwrote the modified version in TFS effectively discarding the whole client-site change (just like if I'd chosen resolve conflict keep mine - however it never asked me about the conflict or suggested that there was one, just silently lost it)
If you eye-ball the changes before committing you can see that the changes you are making are more than you thought - i.e. the client site changes are effectively being removed and will show as differences - however it's easy to miss this when you are doing it a lot.
I had previously thought to blame coworkers when they skip out my changes this way, but now I've actually seen myself do this to myself I realise the tool is deficient. Hard to believe but there is obviously something wrong with the way it merges your locally changed file against the 'get latest'. I'm using a cloud TFS with a flaky network connection sometimes - I'm told this contributes to the issue.