I have used many version control systems and most of them restore the file's date/time on checkout. This is not the date/time it is checked out, or checked in, but the date on the actual file. TFS uses the date the file was checked out.
So, I'm trying to find out what is in production. The date of the file is 10/3/2014. I have an 8/3/14 check-in, and an 12/3/2014 check in, and 49 check-ins following that. The 8/3 does not match what is in production, clearly changes were made after that. So, I want to get the latest version of each file that was before 10/3/14 on it's modification time (check in date is as always, useless)
Now, in a "normal" company, there would be a version label applied when it was built and pushed to production - but we are working with off shore (India) developers who don't do that sort of thing. It appears that most of the 49 changes didn't make it to production, and will be rolled back.
I ended up taking file by file and trying to get something that built, and seemed to match what was in Production as best I could - and spent days putting the project back together. (It seems developers copied files between them instead of putting them into TFS - so different people checked in different pieces of the puzzle - many versions didn't even build.)
In any event, I didn't see any way to query by real modification date. I get how pulling files down with the correct modification dates would result in a requirement of a build-all, or deleting the object file result of that source file (in order to force a build) - but it sure would be nice to be able to get files changed since a specific date/time.
If i understood your problem correctly, you can query history of projects with commandline tf history with version option set to your interesting date. https://msdn.microsoft.com/en-us/library/yxtbh4yh.aspx
Related
I know I can look at the "Source Control - Team Foundation" output in the Output window but it's hard to tell where the results from the current request begin and the last request ended sometimes, and any files that I want to compare that are in the list I have to go look up.
In the past when I used subversion, I had a tool (I think tortoise) that did an awesome job showing me all the files that were changed and I could click directly on them to compare with latest version. I would often use this to do quick code reviews, and it made it much easier to make sure I wasn't about to get an updated project file that had been improperly merged.
Are there any extensions/plugins or anything that can help with this for TFS when getting latest?
Unfortunately there isn't such a tool can exactly achieve that, there is a user voice submitted here, and it's ARCHIVED.
Based on my experience, the best thing to do is a folder comparison before you get the latest version. In Source Control Explorer, you can compare the differences between two server folders, two local folders, or a server folder and a local folder. Right click on the target folder and select Compare. Read more here.
To see the changes block you can introduce the third compare tools. (e.g BeyondCompare, ExamDiff, Code Compare etc, you can reference my answer in another thread : Visual Studio TFVC Merge Lines Misaligned). In short you can get the change list from Output window, then compare each file accordingly.
Besides, you can also try using the Tf Command Line Utility and the Visual Studio extension Diff All Files for VS2013. Reference this thread for details : TFS Shortcut to do a diff on all modified files with latest version
I am currently faced with a situation where I am working in a TFS repository that has a large source control folder dedicated to the database. There are sub folders for various database objects like tables, stored procedures, functions, etc. Right now our team is expected to create a DB code review task each time we check in a database change against one of these objects. Over the past couple months I have had somewhere between 40-50 check ins touching various database objects. The problem is that this is not really efficient because a material percentage of these check ins and subsequent reviews become a waste of time because chronologically later check ins make that code obsolete. I am just one dev on an 8-10 person team too, those poor DBA's!
I have what I think would be a working solution but I don't think it's possible to get this data out of the UI (at least in TFS 2012) and I'm not sure how to even begin a query to get it (assuming they will even give me access to the tfs db).
What I would like to get is a result set including all modified files within a specific source control folder and sub folders between two dates. I would then like to be able to get the id of the changeset that was in effect at the beginning date and the changeset id that was in effect at the end of that date.
The table would hopefully look something like this:
File1 - BeginningChangesetID - EndingChangesetID
File2 - BeginningChangesetID - EndingChangesetID
This way we could structure our DB code reviews such that we can provide a file name, the beginning changeset and the ending changeset. This would allow the DBA to pop open source control, navigate to the file, right click and compare those two versions of the file and then be able to provide meaningful feedback on code that is relevant. If anyone has any recommendations on how to extract this information from TFS it would be much appreciated! Sample queries would also be great. If this data is retrievable through the UI in a version later than 2012, I'm looking for that as well.
If you right-click a folder in the source control explorer you have the option to diff the folder. In the Diff window you can select the version of the folder to compare on both sides.
Set the source to:
$/Project/Folder
[SERVER]
Version: date
Set the target to:
$/Project/Folder
[Server]
Version; another date
You can configure what to show, it seems you're interested in: most options, in source, in target, changed.
You can achieve the same thing from the commandline:
tf vc folderdiff $/Project/folder;D"2017-01-01" $/project/folder;D"2017-02-01"
/recursive /view:different,sourceonly,targetonly
tfsI get my some of my local files replaced with another version when I check in a new version of my project.
We use TFS 2010.
Here's the situation in more detail:
A colleague made significant and incomplete changes to the project leaving it nonfunctional, checked in that code and went on a two week vacation. Since these changes were not even required the obvious course of action is tho get the previous version and work from there.
The problem happens when I check in the new working version of the project: instead of just delivering files to the server I get files replaced on my machine with the server version. I never would have thought checking in would get files from the server!
When you check in your changes, Visual Studio will always try to merge them with the latest version on the server. It must, because the version history of each file is linear, unless you manually branch files.
If the changes on the server are incompatible with your local changes, the checkin will be blocked and you will have to resolve any conflicts locally before you can check in again.
What you're seeing is expected behavior and it cannot be different due to the way TFVC works. Your colleague should not check in a version that doesn't work. In such cases he should create a shelveset (which will store the files seperately from standard history).
In your case I'd select the checkin from your colleague, select Roll back and check in the result of that. It essentially removes his changes, but they are not lost. By re-applying the rolled back changeset (roll back the roll back changeset) or by getting the specific version with the changes he can continue working on them.
I'm not sure why I never noticed this before but when I "Get Latest" from TFS, the date and time on the files in my local working folder are set to the current date and time. This applies to the Created and Modified dates, even if no changes have been made (as I just did "Get Latest", nothing more).
Should I be concerned about the dates and times of the files not reflecting the true date and time the file was created and subsequently modified? I have the revision history in TFS so I'm not overly concerned but I gotta admit this feels wrong. Everything technically works but I want to know what's going on.
As you note, the default behavior in Team Foundation Server is to write file times to the "current" time (when you retrieved the file.) This is the default behavior of most version control tools and generally considered safe.
Setting time to the remote time can have negative consequences in many scenarios. For example, make will scan for files newer than the last build time. Setting file times to the server's time can impact the ability to determine which files have changed since the last build.
However, if you do prefer this behavior and are using at least TFS 2012 and Visual Studio 2012, you can enable it on a per-Workspace basis by setting "File Time" to "Checkin":
Additional details from Microsoft:
File Time:
Choose Checkin if you want the date and time stamp of each file to generally match the stamp of the changeset of the version in your
workspace. A few issues and exceptions are:
When you modify the local file, the date and time stamp will match the date and time when you modified the file.
This feature is available only if you are using Visual Studio 2012 or later and Visual Studio Team Foundation Server 2012 or later.
The setting does not apply to folders, unless there is a pending add or delete operation to a file contained by the folder.
You might not be able to build your code project incrementally. Instead, you will have to rebuild).
Choose Current if you want the date and time stamp to match the date and time when you last modified the local file. For example, a
team member checked in the latest change to the file on Monday. On
Tuesday, you perform a get operation to update the file. The date and
time stamp is set to Tuesday.
As mentioned, that is the default behavior of TFS. It's the fist version control system I've used where that is the default setting. The problem with using current time for files when a developer gets latest, is that you can only tell if you have the latest version by doing a file compare on each file. Three different developers on the same project will have 3 different date time values for the same version of a file. Either way, always do a project clean before creating builds. Why? Because you might have tweaked a file or two, then after testing, reverted to the latest checked-in version. In my experience it's always better to use the checked-in time.
TFS should not modify original File attributes in Source Control processing. Its build features should use their own properties to control latest checked in versions and for build control.
Getting files from TFS should place the original file back down on a system with their original properties unmodified. TFS is broken by hijacking the original file's properties for its own purposes. The original Microsoft VSS tool provided this option - shame on the TFS team.
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.)