Since I could not get the latest version automatically with the old SourceSafe (VS 2003), I hoped this was 'solved' with Team System. However, when I tried to get this done, I could not manage it.
The problem I have to deal with is that my colleagues and I work together on the same source (I think that is what has to be done with SourceSafe/TS ). Whenever we change something and check in our source, the new source has to be used. When I check out the source edited by my colleague, I just keep MY OWN source instead of retrieving the latest source. Clicking 'Get Latest Version' does the trick, but that one is easily forgotten and thus should be 'automated'...
Could anybody help me out? I would much appreciate your help/arguments on this one!
It turns out that this is by design, so let me explain the reasoning behind it. When you perform a get operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control. Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that are known to work together, and therefore is buildable and testable.
As a developer working in a workspace, you are isolated from the changes being made by other developers. You control when you want to accept changes from other developers by performing a get operation as appropriate. Ideally when you do this, you'll update the entire configuration of source, and not just one or two files. Why? Because changes in one file typically depend on corresponding changes to other files, and you need to ensure that you've still got a consistent snapshot of source that is buildable and testable.
This is why the checkout operation doesn't perform a get latest on the files being checked out. Updating that one file being checked out would violate the consistent snapshot philosophy and could result in a configuration of source that isn't buildable and testable. As an alternative, Team Foundation forces users to perform the get latest operation at some point before they checkin their changes. That's why if you attempt to checkin your changes, and you don't have the latest copy, you'll be prompted with the resolve conflicts dialog.
But TS makes sure that, you do not check-in your code back without knowing the changed made by others. So when you check-in some code that was not latest, you'll get conflict and merge option that you can use to look into the differences.
You are right. This morning we dealt with a buggy environment, but we solved that part already. Nevertheless, I think it is a pity that I have to merge, even if a GetLatestVersion should have done the trick...
It turns out that this is by design, so let me explain the reasoning behind it. When you perform a get operation to populate your workspace with a set of files, you are setting yourself up with a consistent snapshot from source control. Typically, the configuration of source on your system represents a point in time snapshot of files from the repository that are known to work together, and therefore is buildable and testable.
As a developer working in a workspace, you are isolated from the changes being made by other developers. You control when you want to accept changes from other developers by performing a get operation as appropriate. Ideally when you do this, you'll update the entire configuration of source, and not just one or two files. Why? Because changes in one file typically depend on corresponding changes to other files, and you need to ensure that you've still got a consistent snapshot of source that is buildable and testable.
This is why the checkout operation doesn't perform a get latest on the files being checked out. Updating that one file being checked out would violate the consistent snapshot philosophy and could result in a configuration of source that isn't buildable and testable. As an alternative, Team Foundation forces users to perform the get latest operation at some point before they checkin their changes. That's why if you attempt to checkin your changes, and you don't have the latest copy, you'll be prompted with the resolve conflicts dialog.
Thanks for your answer. It is very clear to me. We are already working some time with TS and the 'designed problem' is not that big :) . It only cares for some conflicts when we forget to 'GetLatestVersion'.
However, I did not mention to get the latest version of my file to checkout. We would have liked TS to get all latest files to overcome some of the time consuming (but safe, thanks!) conflict resolving... I guess some more specification of the application parts to work on would be helpful ;) .
Is there going to be an option in the final release of TFVC to enable automatic get latest on a checkout?
I have read the explanations why a Get Latest is not being done, by design, in TFVC. This may sound realistic to you except that is not how real world developers always, categorically, need to work. Also your rationale implies that .NET code is typically so intertwined and dependant on other modules that worry about dependencies is an overriding concern. This sounds like bad software design you are worrying so much about. We should be able to generally modify OOP code without continually creating a cascade of dependency changes. Is that not the basic idea?
We are in the early construction phase of a large VS2K5 application. We always need to work against the latest. We are having much more problems and inconvenience with forgetting to Get Latest before a check out than any sort of dependency breakage problem as you suggest. In my 8 years using VSS on numerous projects at numerous clients I have never encountered a situation where we did not automatically want to get latest almost always. For your team to decide that everyone was doing it wrong before and force a global change in practice is simply a bad idea
Please give us a choice. We saw an IDE script posted that supposedly would force a GL but we could not get it to work.
I hear ya. I'm not sure I totally agree with your statement about source file inter-dependencies resulting from bad software design, but I too have used VSS on many software projects without being bit by this issue. In hind site, I wish we'd have made it optional. We discussed it at the time, but we were always looking for ways to deliver our core value in a timely manner, and this option got cut as a result.
Unfortunately, it's too late to add it back into V1, but I promise you it's on the V2 list and I've heard enough complaints to be able to fight hard to make sure it stays there. As always, thanks for the feedback.
A related but even more problematic issue is Get Latest doesn't always get the latest file if it "thinks" you already have the latest file... even if you don't!
This can cause horrific issues if not resolved. Yes if you know it is doing this and do "Get Specific Version", select latest version, select overwrite files and select force get, all of that will finally really do a get latest of what in VSS was as simple as selectiong "Get Latest" from the context menu. This is really painful and must be fixed.
What do you mean by "fixed"? Do you want to make Force Get the default? There's probably a way to do that with a macro, but it will obviously be a lot slower.
A related but even more problematic issue is Get Latest doesn't always get the latest file if it "thinks" you already have the latest file... even if you don't!
The only way that the case you mention would occur is if you physically opened up the folder containing the source code and deleted it. In that case, TFS on the server has no knowledge of your actions and still thinks that you have the most current versions of the files in your local cache. It is important to remember that unless TFS is allowed to manage the local cache, you will be at risk of seeing this behavior.
So you're saying that TFS gives us the option to "Get Latest Version" (or "Get Specific Version", followed by Type: "Latest Version"), but then TFS decides to overrule us, and blatantly ignore our request.
What a load of rubbish.
If I select a file in TFS, and select Get Latest Version, guess what...? I want to grab the latest version from the Server. It worked perfectly in Visual SourceSafe 6.0.
At the very least, rather than popping up your arrogant go-away mesage ....
"All files are up to date, No files were updated because the requested file versions were previously downloaded"
...why not bring up a developer-friendly prompt instead....?
"The requested file versions have been previously downloaded. Do you still want to get the latest version ?
[Yes] [No]"
Otherwise scrap that whole "Get Latest Version" menu item completely, if you're not going to give us the functionality it's suggesting. Or provide a link to upgrade TFS to SourceSafe 6.0....
Btw, I see TFS now has a "Get Latest on Checkout" option under Team\Team Project Settings\Source Control, but what should I do if I Compare my PC's copy of a file to the Server's copy, then decide to scrap my changes, and just grab the server's most recent copy instead ?
I don't want to Check Out the file, I just want to - here's that phrase again - Get Latest Version..
The only way is to select "Get Specific Version", click on "Overwrite all files even if the local version number matches the specified version", then manually tell the patronising "Resolve Conflicts" screen that, look, all I want to do is get the latest damn version... stop harrassing me, and just do it !
Perhaps, rather than forcing developers to jump through all these hoops, you should just have a simple "Get Latest Version" menu item, just like in the happy days of VSS.
Ah, you already have this. But TFS decides that it knows better than you, so ignores it.
So, since yesterday's posting, I've managed to install VS2008 SP1. Eventually.
Today, I go into the new & improved TFS, I do a Compare on one of my project's folders, and it shows me a list of differences between my PC's files, and the files on the server.
I pick one of these files, click on Compare Files, and it shows me the differences between my local copy of that file, and the server's copy. Beautiful.
Then I decide I want to check out this file, so I can add these changes to the Server's copy of the file.
I right-click on the file, select "Check Out for Edit", select one of three Lock Type options, click on the "Check out" button, and get an error...
"The item <local filename> could not be found in your workspace."
...so I can't check out this file.
Errr.. what ? It does exist...! You've just been showing me its contents in my "Compare Files" window.
- The <local filename> shown it displays in that error message is perfect, the file does exist in exactly that directory on my PC. - In TFS, I can right-click on the file, click on View\Local, and it'll happily open the file. TFS is showing my local directory name perfectly... - I can right-click on the file, click on View\Server, and it'll happily open the file. TFS is showing the server's copy of this file perfectly, so it does exist in my workspace. - My project's Workspace's local directory name is set to the correct directory on my PC... Everything TFS shows suggests everything's fine.... until I try and do a check-out. When is TFS going to be ready for commercial use ? It was bad before. It's just as buggy now.
I can't tell you how much I hate TFS. It's just a huge drain on resources, finding workarounds to poor coding, and it's random functionality.
The "Source Control Explorer" simply doesn't use "Local Path" names correctly. The tree view on the left of the screen works fine, the files list on the right doesn't.
For example, right now, if I click on a source code folder in this screen and click on Compare, the Target Path shown on the "compare" dialog is perfect, and exactly matches the "Local Path" directory shown at the top of the "Source Control Explorer" screen. eg: C:\Projects\Mikes Software Company\My Application\source code\MyASPNetFile.aspx.cs
However, if I right-click on one of the files in the right-hand part of this window, the Source Path shows an invalid directory name, which seems to have been derived from the names in the project directory tree, rather than using the Local Path which is shown at the top of the screen, (and which I specifically defined under File\Source control\workspaces)
Projects +-- Mikes Software Company +-- My Application Iteration 2 +-- source code and I've told TFS that the local path for the "My Application Iteration 2" folder is
C:\Projects\Mikes Software Company\My Application
Click on the "source code" folder in this tree, the "Source Control Explorer" path shows the correct local path: C:\Projects\Mikes Software Company\My Application\source code
But if I click on one of the files in this folder on the right of the screen, it attempts to use an incorrect local path: C:\Projects\Mikes Software Company\My Application Iteration 2\source code
Once again, TFS thinks it knows better, and gets it completely wrong.
Automatic retrieval of latest version on checkout?
). Whenever we change something and check in our source, the new source has to be used. When I check out the source edited by my colleague, I just keep MY OWN source instead of retrieving the latest source. Clicking 'Get Latest Version' does the trick, but that one is easily forgotten 