We had a user that left the company abruptly and has checked out files under their name. We need these files and their changes that were made to the file. How can we get them in TFS?
If they put their changes in a shelveset, anyone should be able to pull the shelveset and check the changes in permanently. If they didn't, the modified files are wherever their workspace is (was?) and they'd have to be retrieved from there. If you have a TFS administrator, they might be able to get at the workspace definition(s) for that user and back in to a check-out location.
Where I work, workstations are usually imaged when someone resigns so if we need to get at their work it's available for six months or so even if their system gets wiped.
Related
For example I am working on some file.
I want to mark it like a file for the future commit and i want to do it right now because I will have many files and I can't remember all changes in them.
And right now I have no access to TFS (I need to connect to VPN to get access to TFS).
Is there any way to mark a file?
TFVC does not support offline work in the same sense as a true distributed version control system like Git.
With local workspaces, you can modify files without checking them out first. They will appear as pending changes, but you won't be able to check the changes in until you have connectivity to the TFVC repository.
When files in a tfs workspace are moved outside of tfs (eg. through windows explorer), tfs picks these moves up as a delete and an add.
To get around this, I have a program running that monitors for changes and when a move happens I do a Workspace.PendRename with updateDisk set to false.
This works fine except that tfs adds the delete as a candidate change.
Is there anyway to remove this candidate change? It causes issues if people try and promote these changes.
By using Workspace.GetPendingChangesWithCandidates I can get the candidate change, but there doesn't seem to be anything I can do with it to remove it from the list.
Before doing the PendRename, I tried moving the file back to it's original location (File.Move) and then doing the PendRename with updateDisk set to true. This actually works well for single files, but gets complicated when folders and such are involved.
I'm hoping there's a simple way to either remove the candidate change from the list, or to even disable the candidate changes functionality altogether for certain files/folders. I tried adding the folder to the .tfignore file but that doesn't work.
Promote Candidate Changes shows deletes even though files were renamed
In TFS there are two kinds of moving files. I have crated a sample for both :
Local Workspace (window exploer) directly move/drag file
In the disk my workspace, I'm going to move 2.PNG to Main-branch
folder
Then we could check what TFS detects in VS. One with add(in new
place), one with delete(in old place) in Promote Candidate Changes.
You need to check in both the add and delete ( promote first). Finally
you will get what you want both server and local.
Move a file in solution explorer directly
In the solution explorer , I'm going to move 1.PNG to Main
folder by right click and select move.
You will get a pending change with rename status directly and
not any Promote Candidate Changes.
Then we could check our local workspace, you will see 1.PNG is
automatically deleted in the workspace folder even though you haven't check in changes. Finally checking pending
changes, everything is fine and clean.
Back to your question: Promote Candidate Changes shows deletes even though files were renamed.
The TFS API should be using the way 2 above. Look at the parameters :
updateDisk
If true, the local disk is updated according to the pending changes;
if false, the disk is not modified and changes are not
acknowledged.
So if you set the updateDisk to false , the 1.PNG should still exist in the disk and TFS detect it and adding to promote Candidate Changes shows deleted. Which meets your screenshot. The solution should be change the value from false to true.
I've been experiencing some situations where I feel as though what is present in a changeset of mine isn't always representative of what I did.
Example: I incremented a version number in AssemblyInfo.cs through the project properties GUI and in a couple other locations. I then checked in my changes and moved on deploying things.
Come to find out, the AssemblyInfo.cs file had been emptied. I checked on my disk and the file contained binary of all zeros.
This is the most recent event in a series of headscratchingly frustrating changeset issues.
Is it possible for someone to tamper with a changeset without leaving any audit trail, or is it possible that the GUI in Visual Studio is corrupting certain things on me?
When you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to get information about:
•which files were changed
•what the exact changes were
•who changed the files
•what the check-in comment contains
•which work items are associated with the changeset
•which policy warnings appeared
TFS won't tamper changesets if you have a successful checkin. You can try on another client machine to see whether your issue persists.
No, it is not possible to make changes to TFS version controlled files without leaving any audit trail by anyone or GUI.
You are able to check the file's history via right clicking the file in the Source Control Explorer and click "View History". From the listed changesets, you are able to check who submitted the changeset on which date. If you don't want any one specific changeset, you can just rollback it.
I wanted to implement a trial version of my .NET application and I came across solutions that involved saving the dates in the app data folder. The questions I have are related to that solution and I would have commented over there but I dont have enough credits to comment.
So the solution I am following basically saves the created date and last opened date in a folder within App Data folder. If the folder did not exist before hand it creates one and after that checks the validity. That is all very good and it works.
What I want to know is:
1) What if an educated user navigates to the app data folder and deletes the folder. My solution would create a new folder and then it would be like starting over again. What would be the solution to that? I can only think of saving those credentials in different folders and checking all of them. Or maybe create that folder and the credentials during installation (which I dont know how to, I am using InstallSheild Wizard in Visual Studio). So any ideas regarding this?
2) What if originally I gave the client a 30 day trial and I was reading the dates from that folder and then validating. Then sometime later the customer buys a yearly subscription or something. How do cater that change? I could change the validation criteria in the code (I dont think that is very good either) but more importantly how can I sort of reset the app data folder? So that the validation of one year starts from the new installation/update date.
I have very little experience in developing .NET applications and even less in dealing with licenses etc. So kindly let me know a better way if there exists.
You need to hide the file in a secret folder / registry.
You can store subcription info into a file in same folder with the application. Your app will check this file first, if it does not exists, we will check the trail file.
The best solution I found was built right into Visual Studio.
Just go into properties of your project and select settings.
Add the fields you want to save. In my case they were the installed and last opened dates. And set the scope to User.
You can now access those fields by Properties.Settings.Default.%propertyname%
and do validations and set values as required.
At the end just save the settings.
The settings are saved in the hidden application data folder so they are safe from user intervention.
I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).
Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.
We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.
The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.
So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?
It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Otherwise, you might put it in My Documents:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.
For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.
For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.