TFS: Find a moved file by the old name - c#

is there a way to get the version-history of a file if you only know an old name of the file?
I am currently looking at an old copy of our repository (I don't know the exact date, the copy was taken). When I compare it to the current repository, there is one file, that only exists in the copy, but not in the current repository. It has not been deleted in the repository. I guess, it has been moved or renamed. Is there any way in TFS to find the version-history using the old path and name?
I know that I could dig around using the name or some code-fragments. But IMO this is not an acceptable solution when using a repository :)
Thank you very much
Andreas

In Team Explorer 2010, you can simply turn on the "Show Deleted Files" option and navigate to the original folder, you'll be able to then see the file that was moved or deleted. You can view history on the item to see its last changeset - this will show you whether it was outright deleted, or if it was just renamed and thus the item no longer exists in the current path name (aka "slot") and was deleted that way. You can further drill down in to changeset details for that changeset to see the new path name (slot) that item occupies.
As you mention, you could certainly do this with a little bash against the TFS API using the GetItems method. Though I understand that it's not what you want to do, I thought it worth saying just because the TFS API is surprisingly easy to work with.

A couple of simple approaches (not already suggested in other answers) may help:
In your new repository, go to the folder that used to contain the old file, right click and show History. This will show all the versioned changes to files in that folder. Now look through the list of changes for files that no longer exist in the folder, and double click them to view them and determine if the file looks like an ancestorof your new file.
Or go for a brute force approach: get all the source code onto your disk and search for files of the same name, or files with some of the same text in them, as the file you're looking for (I'd look for comments that seem like they might be faily old and which use a distinctive wording that is unlikely to have appeared in many places. Comments are less likely to have changed than class/method names that might have been refactored if the file was renamed)
Grep may be an ugly, brute force way of approaching the problem, but sometimes it's the quickest and easiest. The TFS CLI tools are powerful, but unhelpful, complex and poorly documented, so unless you're already an expert, they can take a lot of trial and error to get them to do what you want.

Related

How to 'combine' histories of two files (one being the older 'version' of the other one)

I basically have what's a poor-man's versioning...
At one point someone copied / renamed the 'file.cs' to 'old-file.cs' - and all its history up to that point going with it.
And then created a new 'file.cs' - with all the new history going forward.
I ended up with the same file having history split up in between these two files.
I know this must be simple (if possible),
- I've tried searching, but my problem is how to 'phrase the question'
- This isn't a 'merge' (I think - I don't have branches involved),
- It's not the typical 'move' either
- I've looked up the tf command line but nothing resembles what I need
- I have the TFS Source Control Explorer Extension installed (but it can't really help with this)
FWIW, I'm using the VS 2015, C# project (both files are part of the same project), though I don't mind if the solution is command line 'tf' or whatever gets the job done.
So if anyone could help point me to the right direction at least it would be much appreciated. Thanks!
I have tested with TFS 2015.3 + VS 2015.3, but couldn't reproduce your scenario. In my test, the history in old file has been migrated to new file. You may check my steps to see whether they are the same as yours:
Rename a file gulpfile.js to old-gulpfile.js, and check it in in Source Control Explorer. Then copy old-gulpfile.js in workspace and modify it to gulpfile.js, and add it to source control and check it in.
Check old-gulpfile.js history:
Check gulpfile.js history:
You can see all history in old-gulpfile.js is also in new gulpfile.js file.

Project looking in wrong directory for files(streams)

I've been building a game for the past couple of days. After i've reached certain milestones i'll C&P the project folder into my dropbox folder then create a new one in my visual studio folder.
I've run across a problem now however where when i'm trying to read from files the streamreader is trying to read from the previous folders directory.
SO for example in 'Project2' the reader is trying to read from a file in 'Project1'. How can I change this?
First, you're most likely specifying an absolute directory ( "C:\Blah\BlahBlahblah..." ) or you've set the Working Directory to the wrong place.
Use relative paths or always store your data in a fixed place (the convention these days is to store your data is APPDATA. Storing it in a place like Program Files is a HORRIBLE CONVENTION. Don't do it when you release your program for realsies). Having tagged this with XNA, your root directory should also be specified to a relative place ("Content", "Data", etc.) so that when the executable boots up, it'll look in where the executable is, + inside the folder "Content" or "Data". That will make using the Content Loader easier.
Now, a general recommendation. You should never have to create a new project entirely to do version control. You're literally doing the work of any good free Version Control System (or like this one). Version control will make this much less painful for you.
Finally, a last tip for SO: describing your problem is cool, but what's even better than all of that is combined is posting the code that throws an error. Doing this allows us to figure out what exactly what wrong, because the skilled professionals of SO (of which I am trying to become one) have dealt with and know how to handle many kinds of exceptions and compilation errors (that, or our Google-Fu is stronk).

Create a Directory using Directory.CreateDirectory( ) that gives a warning message when trying to delete or rename

My application creates several text files that contain important data for its working. I am grouping up all these files in a folder. In Form_load() I gave Directory.CreateDirectory("C:\\xyz"), so that a folder is created in a drive which will later include text files, when the application will be delivered to clients. I want to see that the user does not delete or rename the folder. A dialog box that shows some warning message will be helpful. Is it possible with Directory.CreateDirectory()?
I think you should just warn the user about the importance of this directory. However, you can recreate the directory by performing this kind of check :
if(!Directory.Exists(path))
Directory.CreateDirectory(path);
From this point, you can imagine a mecanism that save the important files in a temporary way, and if the directory is deleted, you recreate it and put the previously saved files in it.
First of all, you might find reading this helpful.
Second: If I understand your needs correctly, what you want is much more painful than you think.
You should really consider doing what Damien_The_Unbeliever told you.
However, if you insist: You will need to use C++ (C# will give you and your users a lot of pain) for it, and you will need to "hook" SHFileOperation through something like ICopyHook. Start by taking a look at ICopyHook. It will be a lot of work and a lot of learning, and I don't think it's worth it, but there's the info. Good luck.

When editing Resources.resx file, Resources.Designer.cs fails to update because TFS doesn't check it out

I'm using TFS source control.
When I add a new resource key to my resource file - Resources.resx - and hit save, TFS checks out Resources.resx but doesn't check out Resources.Designer.cs. This causes the update to Resources.Designer.cs to fail with error:
The command you are attempting cannot be completed because the file 'Resources.Designer.cs' that must be modified cannot be changed. If the file is under source control, you may want to check it out; if the file is read-only on disk, you may want to change its attributes.
The error is correct in that the file IS read only and the file IS NOT checked out. I don't want to have to manually check out the designer every time I add/edit a resource key. Does anybody know of a solution or work around to this issue?
Note that I have TFS set up to "check out on save" as opposed to "check out on edit". This is deliberate to reduce the amount of unedited checkouts.
EDIT:
This happens in other file types also. For example, I am using RazorGenerator to create compiled MVC views. The same problem occurs if I try to edit the .cshtml without checking out the .generated.cs first.
UPDATE:
This issue occurs on all (as far as I've seen) files that have an autogenerated code-behind: .resx, .edmx, .aspx, .cshtml (when using RazorGenerator for compiled views), etc. I've decided that it's not worth the pain just for having "on edit: do nothing" set. I've decided to reset this to "on edit: checkout automatically". Thanks to everybody for your input. No thanks to TFS team for this FAIL.
Well, I did not think this counts as an answer so I wrote it in comment.
Checkout on save is only triggering when you save file, it does not trigger when file is autogenerated (autogenerate is not trigger for save which does checkout, as this file is edited by custom tool assigned to resx).
I'm afraid you will not get proper answer (the one which will solve your problem) besides that it is by design, but it may be worth opening a case on connect and ask to change this behavior.
Why do you want to reduce the amout of unedited checkouts? If a file is checked in without changes, TFS notices and it will not show in the checkin history of the file.
You can test this yourself by checking out a single file and immediately checking in. TFS will tell you there where no changes and the checkout is undone.
So maybe consider setting it back to checkout on edit? As mentioned in the other answer, this will solve your problems...
I think this is the problem
Note that I have TFS set up to "check out on save" as opposed to
"check out on edit". This is deliberate to reduce the amount of
unedited checkouts.
To avoid above problem, revert back to default settings. Then download TFS power tools.
Then use this command to revert changes which are checked out but contain no edits
tfpt uu /noget
Update: On changing above setting the issue no longer occurs. For details, refer below discussion in comments.
I have to work with TFS at work. I've seen to many miracles and we've spend a lot of time figuring out where the problem is. TFS is the choice of my company, but it's not my favorite.
TFS (especially when server is slow and you have regular network problems) is a disaster for me as a developer. VS looks for modification only over files in solution, and as you can see not all of them. When you use third party tools (fitnesse for integration tests or custom build steps) wich requires to modify files outside VS - you'll probably get the same error as you have.
But we found a solution. On my machine I use git. We've installed git-tfs.
And all you need to remember is three magic commands
git tfs fetch
git merge remotes/tfs/default
git tfs ct
That's it. You will never break company rules. And at the same time you will be free of that kind of weird problems. We've forgot about that nightmare.
EDIT: Local workspaces in the upcoming TFS 2012 will solve several issues, and TFS 2012 will become closer to SVN, but it will not be DVCS. MS invest in integration with external DVCS - please, welcome - Git-TF.

Identify renamed and modified file in Git using SHA1

I'm hacking around git repository at low-level, trying to retrieve file's history from it. And having difficulties identifying file modified and renamed in a same revision.
I'm developing C# application and I need to implement git log --follow FILENAME feature.
Modification is simple: search for file with given path in trees attached to revision, if SHA1 differs — Voilà!
Rename is simple too: if search by given path was not successful — look for object with same SHA1, as previously, if found — Voilà!
But if not found it might be either file deletion and my search is over, or rename and modify in same revision... but how to distinguish between these cases?
I've studied everything I found regarding Git internals, but still cannot find out what to do in this case, what might be common between tree objects corresponding to the same modified and renamed file in different revisions?
Many thanks in advance for your help!
Git allready has that functionality. See -M/--find-renames, -C/--find-copies and -C -C/--find-copies-harder options to diff (applies to log and show as well) and --follow option to log.
The principle of --find-renames is, that if it sees new file in a revision, it looks at the files removed in that revision, compares them and if any is similar enough, declares it a rename.
Edit: In more details: To detect copies/renames, git compares the two revision first it compares the lists of files. Than for each path that only appears in the new revision it compares the content with content of files from old revision that -M—were deleted, -C—were modified or -C—all and if they are similar enough (which requires diff), marks it as rename or copy as appropriate. This is part of the diff core and is available to all commands that show diffs in any form, including the name-status, which does not do detailed line-by-line analysis. On top of this the --follow works by iterating the revisions one by one, does a name-status diff with rename detection and outputs the revision if the file was modified and remembers the new (old) name when it was renamed.

Categories

Resources