I have a scenario I am hoping someone will be able to help me think through and determine the best way to handle. The tools I am using are Visual Studio 2013 and TFS.
We had a developer leave our company abruptly, and he has a lot of code changes for a client project which were not yet checked in. We have the code base with his changes locally. We also have the client's TFS server with the latest code. I do not have documentation of his changes, so my goal is to find all the code changes he has made. Keep in mind I also do not have access to his machine, I just have access to the local code base which he was working on, which includes his changes.
I began by comparing his code with the client's code on TFS, and looking for changes. However the client has also made some changes to their code in the 2 months since this developer began working on this project. So within those two months he made some changes locally and the client also made some changes which were checked in on TFS.
When I compare his code to the latest copy of code on the server, I can see the differences, but I can't seem to tell who made the changes. If a method was modified, I see that different versions exist on TFS and in this local code, but I cannot tell who made the change. Did the client make the change to the code, and the newer version on TFS makes my version look out of date? Or did this developer make the change to the code, making the server code look out of date? As the changes done by our developer were not checked in, I do not have a history showing me who made the changes to the code. What would be the best way to determine the changes our local developer made?
So, to sum it up: I have compared his local code to server code, and have seen the differences, but the client has also made changes to code since he acquired it. So the differences between his code and server code could either be due to his changes or client changes, but I don't know which.
I see a few ways which could make your life easier, but it requires you to know which version your developer initially downloaded. With that version (Changeset, Label, Date) you can make a comparison against the local workspace and find all the changes to that version on the server.
Workspace version
You can initiate the diff from the commandline (as well as from Visual Studio, but command lines are much easier to post on Stack Overflow):
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;C12345" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly
In the place of C12345 you can either enter the Changeset number that was used to create the workspace on your developer's machine or the label (use Llabelname instead of Cnumber) or the (approximate) date (use D2014-12-20).
This will output a list of files that have changed locally against the version that was used to create the workspace. Now you can list each file individually using:
tf diff c:\sources\changedfile.cs /version:C12345
(or use the same version spec as above if you used Labels or a Date).
There is another option, if the workspace is still registered on the TFS server, and that is to compare against the workspace version:
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;Wworkspacename;owner" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly`
Followed by:
tf diff c:\sources\changedfile.cs /version:Wworkspacename;owner
You do not need to own the workspace in order to do this, but the server must still have a record for that workspace on the server. You can try finding the workspace using the command:
C:\Sources\>tf workspaces /owner:avanade-corp\jesse.houwing /computer:jessehouwing
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
Collection: http://your.client.tfsserver.com:8080/tfs/ProjectCollection
Workspace Owner Computer Comment
----------------------- ------------- ------------ ----------------------------
JESSEHOUWING Jesse Houwing JESSEHOUWING
The example above would lead to:
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;WJESSEHOUWING;Jesse Houwing" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly
Create a shelfset
If you do have the option to get access to the system (even if logged on as a different user) you can take ownership of the workspace and create a Shelveset of the changes. You can then unshelve these changes on a more recent workspace and Visual Studio will prompt you to resolve merge conflicts. TFS will know which changes were made by the other party and will try to auto-merge the changes as best it can.
Related
I am working in the enterprise on Visual Studio 2013 and Team Foundation Server. We have a test source and a production source, and I Get Latest on them both regularly. As there are only a few developers, we make changes directly in test, we don't have personal branches off of test (though when our shop was bigger, we did).
So I opened a file in Test, made a simple change to it, saved it, checked it into test, and published it to production. When I went to merge Test with production, I spawned a merge conflict. I am looking at the "server" version and the "local" version and neither one is correct. The "server" version is the file I edited, minus the edit I just made. That makes sense. But the "local" version is something I haven't seen before, what looks like perhaps an older version that I've never never worked on. Maybe this was my local copy and Get Latest didn't update it. But the local file I edited was exactly what I expected it to be.
So, what could cause that? How do I troubleshoot this problem? All I want is to get the correct version in TFS so it doesn't get blown away later, but I have no idea how to proceed.
This may due to when you do the get latest option, TFS didn't update the workspace correctly.
A clean way to do this, back up your file with changes, undo your pending changes. Delete the old workspace, create a new one. Get latest version from server for both test and production source.
Edit the specific file with changes, check it into the test, and finally do the merge Test with production again.
As usual I extensively searched for a solution before asking here, I'm really stuck.
I'm currently working on a customer TFS server and I have no administration rights whatsoever. Me and a colleague were using the same user account, which I know is a bad practice but again I had no choice here.
Today we found out that the account is expired and the customer is saying that it will not be reactivated. Instead they gave us a new account.
The problem is that in our local workspaces we had some uncommited changes. I'm trying to find a way to reassing the local workspace to a different user but every path I tried leads to a dead end.
One thing I tried was to access the current workspace and set it to "Public" so another user can work on it, but I can't access the current workspace as I am offline and the user is expired.
If I change TFS credentials and try to Get Latest Version or anything else I don't see the old workspace but only the workspace(s) of the new user, which has no "Use" access to my local workspace.
I also read that a manual merge of the changes (using KDiff or Winmerge) is discouraged as TFS doesn't see edits done outside VS so it wouldn't know the files have been modified. I personally noted this behaviour when I tried to change some nodes in .csproj files with Notepad++ and TFS didn't give me the file in the pending changes.
Anyone knows the proper way to work with a new user without losing the local changes?
Thanks.
1)Create a branch for the latest change set from the server
2) Check out the files to your workspace
3) Overwrite the files in worspace
4) Now the branch contains your changes
5) Merge the branch which contains your chnages with the latest.
You have three options:
If you are using TFS 2012+ and VS 2012+ you can create a new workspace as the new user and make it a 'local' workspace rather than a server workspace. Then just drop the changes in a VS will detect them.
If you are using an old version of TFS and/or VS you can use the 'go online' option (2010 only)
If you are using a really old version you may need to checkout the entire workspace before dropping the changes back in.
Update: In order to achieve a merge of the changes you could create a branch from the last/latest changeset that you 'got' from the server. Then just overwrite you files... You now have a branch with just your changes and you can then user the merge tool to stitch it back together.
note: Also note that you should check in code frequently (at least daily) to avoid this issue in the first place.
Thinking about using Team Foundation Server with VS2012 or VS2013. Does TFS track every single local change? For example. If I save a file 10 times locally even though I don't check in, will every one of those local saves be checked in on the TFS server so anyone on the team can see? Of does it just send to the server the latest saved version of the file when you check in? I'm not looking for it to do this because it wouldn't seem to make sense unless a manager wanted to track your hours or something.
MSDN describes the checkin process over here. It is stated there, that...
... all the included file changes from your workspace along with the comment, check-in notes, and links to related work items are stored on the server as a single changeset on your server.
That means that only the last version of your changes made locally will make it into the changeset, onto the server and to your coworkers. You can save as often as you want beforehand, the server won't notice.
Short answer: No.
Longer answer:
I can't think of any SCM that works that way.
Here's how it works, with pretty much any version control system (the terminology will differ from SCM to SCM, but the concepts are the same):
You start modifying a file.
You change the file as much as you want. When you're done, you commit it/check it in.
The contents of the file at that point in time are what's stored in the SCM. No intervening changes are stored.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.