i have a strange behaviour in my Visual Studio 2015 when i hit Get latest version.
Sometimes i need to do this twice to be sure that the latest version is fetched.
I look at the output window when it says All files are up to date. everything is fine.
Is this normal?
Well, you don't have to do this. When you do a get latest option in VS. You can do this in source control explorer. Right click the file and get latest.
After doing this, you just need to check a column of source control explorer which called "Latest", the value should change from "No" to "Yes".
Update Screenshot
#D.Konosov Well, if so you still don't need to pay too much attention for this. Since even though you do the get latest. It's still not "the really latest” in many cases. More details for your reference Why doesn't TFS get latest get the latest?
And during the time from your working on to checking in source control. Some others of your team very likely checked in another version. You still have to resolve conflicts for your code.
In my opinion, you don't have to do this. Every morning, when you start working, do the "get latest" once, and after you fininshd the work on it. Check in it in TFS. You may have to resolve conflicts during the check in option.
Certainly, if you insist on keeping this behavior, keep it. After all, it's nothing business.
Related
I want to be able to see (in VS2013 UI) till which change-set I updated my files.
The reason I ask this is because of the following scenario:
I created a fix, checked it in and continued working on something else. One day later, my colleague is testing the bug I solved but found it unsolved. Next, I tried to reproduce it at my machine but was not able to do so. So I wondered whether my colleague got the latest version before starting to test, he was convinced he did, but we cannot find a way to see on what change-set he is.
It is important for us to know this information without getting the latest version and retest it. Since the testing procedure for this bug takes quite some time, and time is valuable.
I'm quite new to TFS and we just switched from SVN to TFS. At SVN, using tortoise, the revision of the local working copy was highlighted, so the user knew which revisions he missed or was at.
I would like to be able to get this same information via VS2013.
I searched the web and found this other question but it uses the command line and I want to see it in the UI. Beside that, I couldn't get the command to work.
The question: Where can I find the number of the change-set in the VS2013 user-interface, my local working copy is on?
One place I know of is in the source control explorer window of Visual Studio.
1: right click a file and go to Advanced->Properties
2: Under the general tab you will see "Workspace Version #" and "Latest Version #"
In the Source Code Explorer you should have a column for "latest". This will tell you at a glance if you have the latest or not.
I got the latest code for my database project. When i check in my stored proc, It simply overwrote the TFS version and it didn't even prompt for any Merges or differences.
Wondering if there are settings that i have to take care?
TFS will only prompt for merges if someone has checked in (modified) the item after your check out. If the item hasn't changed since your check out, your check in will simply put your version in place over the existing version. That is expected behavior.
When I check-in at my desktop (or laptop) and later changes computer to opposite one and requests a get latest then TFS won't update any files just checked in. The only way I've found to fix this is either to delete the local project or executing a get specific version that says to 'overwrite all files even if the local version matches the specified version'.
I'm thinking this is either because I'm using the same TFS account on both computers. Can this really be true? Working on multiple machines as the same user must be a common scenario.
What approach should I take to fix or avoid this issue?
It is because of the duplicate login. I had the same issue. There was also a bug back in the day (don't remember which version) where Get Latest didn't actually recurse through the directories correctly. I just got specific version every single time. It wasn't that much harder (4 clicks vs. 2) so I've just gotten used to getting specific every single time.
We've lost at least one changeset in TFS (we don't know yet if there's more, could be none). We noticed a changeset that was at the top of the list is now gone. We think there might be two at least because the symptoms below also exists for at least one other file we've discovered. Additionally, we can see a hole in the changeset numbering sequence, and we don't believe the changeset with the file described below is that one.
The single file involved had one line changed, and the version in TFS has the file before the change.
Doing a get latest or get specific version gives me the old file, before the change.
After doing the "Get specific version", in Source Explorer, in the column that shows workspace status, it says "No" indicating that the file is outdated. Nothing I've tried so far gives me the file with the change that was checked in.
If I try to view the file from the Source Explorer, it says my file is out of date and asks if I want to view the server version or the workspace version. Selecting the workspace version gives me the file before the change (probably because I did the get specific version above), selecting the server version gives me nothing, dialog just goes away.
If I check out the file, and redo the change, and try to check in, it says that a newer version exists on the server and asks me how to resolve. I can pick discard local changes or discard server changes. Since I want to check in my changes, I select to discard the server changes, but when I try to check in again (conflicts in TFS stops the checkin process), it just repeats the conflict and asks what to do.
Basically:
Changeset is gone, verified with the developer that checked it in
File does not have the change on the server
Server is confused regarding version of this file, complains about outdated version if I try to view it
Won't let me check in changes, just repeats a conflict with a newer version, presumably the file the developer checked in that for some reason is no longer available through a changeset
So... anyone had this problem? This is TFS 2008 with everything I know of updates applied, including all service packs on the developer machines, running Visual Studio 2008 Professional with Team Explorer 2008.
What do I do? Is my only recourse reverting to the nightly backup?
Edit: Things I'm trying after posting the question:
Checking disk space on server hosting the SQL Server (same as the TFS server): Plenty, 6GB free on one disk and 9GB free on another. Perhaps not plenty enough for the future, but easy to increase (virtual machines), but should not have anything to do with our current problem.
No change: Recreating a fresh workspace in a different folder on disk (I deleted them all before adding a new one), doing a "Get specific" version on root folder of project and checking the bottom two checkboxes (overwrite writeable and overwrite all), afterwards says that I have the latest file (Yes in that column I mentioned above). Viewing the file shows me file before the change. Doing a "Get specific" version on that particular file makes it turn to "No", same problem with checkin.
Solved??
I did another checkin on a totally different file, not including the file we had trouble with above, but that file was "attached" to that changeset, even though it was definitely not checked in by me when I tried this.
In other words, it looks like the part of the changeset that related to the file was still in TFS, with the right changeset id, so when another changeset appeared with the same id, that file became a part of it.
Has anyone experienced anything like this? It doesn't really improve my trust towards TFS if things like this can happen.
We still have another file that misbehaves, I will have to see if it has all of the same problems or not and what, if anything, we can do with that. If that file is related to the other changeset we seem to be missing, I don't think we can get that changeset into the database unless we fire up a SQL tool (which I'm really not going to do.)
We used to use SourceSafe, and one thing I liked about it was that when you checked out a file, it automatically got you its latest version.
Now we work with Team System 2005, and it doesn't work that way - you have to "get latest version" before you start working on a file that you've checked out.
Is there a way to configure Team System (2005) to automatically get the latest version when checking out a file?
There's a Visual Studio Add-in for this that someone wrote:
http://blogs.microsoft.co.il/blogs/srlteam/archive/2007/03/24/TFS-GetLatest-version-on-check_2D00_out-Add_2D00_In.aspx
Are you sure you want that?
It means that when you check out a file, it will be out of sync with the rest of your files. Your project may not build or function properly until you update all files.
#Vaibhav: Thanks a lot!
#Jay Bazuzi: I understand what you're saying, but for me it's very important that if a developer is working on a file, it be the lastest version of that file. Otherwise the check in introduces a lot of problems. If for some reason, as a result of the getting latest version, the project doesn't compile, then by all means get the latest version of the whole project. For the way our team works - often check-ins - this is good. If you made changes you want to keep - shelve them.