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.
Related
I have shelved my changes in TFS which will be checked in few days time. Now i want to work on different TFS card which belongs to same file. How can i work on the same file when its changes are not checked in yet ?
How can i work on the same file when its changes are not checked in yet ?
You should use Branch. You can create a new branch based on file are not checked in, then you work on different TFS card with previous branch, after that, you can check out the new branch to work on the same file when its changes are not checked in.
Shelvesets are per-user and differently stored in the source control - it is not possible to merge shelvesets, there's no history etc. The only action possible is unshelving; you cannot even merge files while doing so. So, we only use it as a temporary storage for things that are not finished yet and thus cannot be checked into a branch.
So, you should use branches. Maybe a Main branch and different development branches for features & bug fix.
Hope this helps.
I started using TFS since VS2010. By that time I already created my own TFS server (myname.visualstudio.com). My problem is that I created a new project on the my TFS website (the one with the dashboards). Then when I go to VS2017, and connect to that new project, it asks me to map and get it as expected. Instead of just clicking "Map & Get" button, I instead clicked advanced so that I can configure everything.
On the workspace configuration dialog, I noticed that VS names it as "MYPCBLABLA_1". If I try to remove the "_1", VS says that "the workspace blablabla already exists on computer blablabla", and does not let me use my existing workspace name.
Why does it do so? Can I not use only 1 workspace? From what I understand of workspaces, it is the container of my projects, so different workspace, different set of projects. But what are they really?
Additional info:
I don't know if this helps but on the past, I used to format my PC many times, I'm not sure if that affects the mappings or workspace names when I use VS after reformatting.
Workspaces are maybe the least well-understood feature in TFVC. And you are right in saying they're a way to isolate different sets of files from a TFVC repository.
A lot of people configure a new workspace for a specific project or set of solutions, but let's look at some of the ways workspaces can be used in detail:
Hotfixes: you may need to create a hotfix for something happening now, but you have pending changes in your existing workspace. Instead of shelving these changes, performing a "Get Specific version" on the bugged version, you can also create a new workspace in which to solve this particular problem. After completing the fix you can then continue working with the other workspace without needing to do anything.
Experiments: you may want to do some major refactoring, restructure source control or some other highly impactful operation. Doing this in a new (temporary) workspace helps you prevent messing up your normal work area.
Reviewing other peoples changes: When performing a review on another person's changes, you may want to have a local copy so you can run, annotate and play with the other person's code. Instead of taking these changes into your own workspace, you can easily bring these into a temporary workspace, which you can safely delete afterwards.
Performing a merge, while you are working on other changes: It may be the case that you're working on a new feature an already have some changes merged back to another branch when a release needs to be shipped. In order to prepare this release, without picking up changes or overwriting work in progress in your current workspace, it's often easier to perform these kinds of release activities in a temporary workspace, that way you know that the work is always done on the exact version in source control.
Preventing accidental changes to important branches: By putting your production branch in a separate workspace, you can't accidentally combine changes from say Development and Main into a single check-in. Since Visual Studio often auto-selects all pending changes in the workspace, this may cause unintended changes to your master/main branch. I've written a Check-in policy to prevent these issues, but having separate workspaces is a much safer solution.
Working with multiple developers on the same workstation/server: in some organisations, developers use a remote desktop to a central beefy server to do changes. To ensure each developer has his own set of files, each developer gets his/her own workspace. An alternative is to make the workspace public, which allows multiple developers to use the same workspace folder. But this often leads to all kinds of unexpected issues.
Browsing an old version of the code: if you need to review/compare an older version to a new one, you can often get away with the folder diff view in Visual Studio, but if you need to do more thorough comparisons, you may want to have 2 copies of the same folder in your TFVC repo. Creating two workspaces will allow you to have two different versions of the same folder on your local disk.
Prepare a special version for merges or labels: You can merge and label the workspace version of a set of files. You can create a workspace and then use Get Specific Version to fetch specific versions of specific files, these can all come from different changeset versions. Once you're satisfied, you can perform the label or merge or branch action to store this specific workspace version configuration on the server.
As you can see, Workspaces allow you to do parallel development on one machine, isolate changes etc.
Be creative
As you can see, workspaces are a very powerful concept. Usable for a lot of operations. But you need to understand the concept thoroughly. Many developers don't understand exactly what workspaces are and how they work, they're missing out of some of the most powerful concepts of TFVC.
Consolidating and cleaning up
In your case you now have two workspaces. In order to consolidate these (if you want to), you can unmap the folders from your _1 folder and then map these same folders in your original workspace. You can also delete the _1 workspace from the TFS Server and then update the mappings of the original workspace.
Remember that workspaces are stored on your local machine, but that the TFS server also has a registry of who mapped which TFVC folders to which workstations. So simply deleting files from your local disk is not sufficient. You need to save these changes to the TFS server (this happens automatically after performing a get operation after changing the mappings).
To check which workspaces are registered to your workstation on the TFS server, use:
tf vc workspaces /computer:YOURWORKSTATIONNAME
Then delete old workspaces with
// DELETE the local workspace
tf vc workspace /delete:WORKSPACENAME
// DELETE the workspace registration on the TFS server
tf vc workspaces /remove:WORKSPACENAME
To prevent the creation of a new workspace by VS, I:
Create a local folder to which I’ll map the content of the remote repository;
In VS, connect to the remote repository;
In VS, open Source Control Explorer and navigate to the content I need; VS will show a “not mapped message”.
Click on that message and map locally.
This guarantees that no other workspace will be created, and the current one will be used.
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.
We have multiple developers on our team. This works for everyone except one developer, but we cannot seem to find the reason it does not work for this individual. We all have VS premium+, TFS 2012 power tools installed.
We have a branch. We get latest version from branch. Go to windows explorer and delete all files in folder "sdk" (there exist no subdirectories in sdk/). Then we copy into it a bunch of files. (This effectively leaves some files as new files, updated files, identical files or removed files when compared with what was deleted.)
When we go to pending changes, these changes show up under "Excluded Changes - Add(s) 51, Deletes(3)".
Except for one developer. His system does not recognize these changes. What might cause this to not work for him?
If it helps troubleshoot, he is also the only developer that if he were to delete these files via power tools delete option in windows explorer, his .dll files get locked. This does not happen for anyone else either.
This is what we've checked so far:
EDIT: Solution Found - Thank you all for the responses! It was indeed the local vs server workspace option. Setting his workspace to local solved these and a few other issue he was apparently having.
Make sure that the developer is using a "Local Workspace" as opposed to the "Server Workspace".
This is a concept which was introduced in TFS 2012 which helps developers to work offline as opposed to server workspace in earlier versions which did not allow that. TFS 2012 changes up the workspace options. Server workspaces are still available, and work exactly has they have in previous versions. However, TFS 2012 now contains a new type of workspace, called a Local workspace. Again, this is an oversimplification, but in a Local workspace, all the files are read/write, not read-only. The meta-data about the files is stored in a hidden folder in the root of the workspace, which allows edits, renames and deletes to be done locally without any communication to the server.
This improves the offline story with TFS significantly, as you no longer encounter issues with editing read-only files. It also makes it easier to work with other tools (such as Notepad) to edit code files. Making a change to a code file using Notepad will still mark that file as edited, which will be picked up by TFS the next time you connect.
LINK
This only ever happens when a user tampers with a local view of source control (be it a local workspace, or not). If all you ever did was get latest from TFS this would never occur, instead, the local view of what is in TFS would always be properly managed.
Also sounds like a bad merge, e.g. getting latest (where the files no longer exist) then copying in old content (introducing untracked files.) One thing you might try doing to correct the issue is doing a forced fetch from TFS after deleting the local workspace contents BEFORE attempting a merge. This will ensure that the local workspace is up to date an accurate with what the TFS server believes is truth, if it still occurs after merging in content then the problem is almost certainly within the merge process the user is going through (i.e. PEBKAC, or a knowledge gap about what they are doing.)
If you unshelve old content (pre-deletion) into the local workspace (where the deletions have already been performed, according to the SCC, and thus locally because of a sync/get-latest) then the unshelved files will effectively become untracked and it's up to the user to clean up the mess. This is identical to a user having copied loose files into their workspace that TFS never had any knowledge of. TFS isn't going to prune untracked files for you, I believe some other source control tools might do this as a configurable default, TFS does not.
That this is only happening to one developer in the team suggests that the other developers, one at a time, should sit with this developer and drive using "their process" to see if it still occurs for them. More often than not this comes down to a bad process a user has adopted, and putting a different person in the chair can help highlight why it has been occurring and help end it. A disciplined build/source manager and/or developer should not experience this problem.
Very interested in knowing what the problem turns out to be.
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.