Disclosure: Newbie with TFS and couldn't find useful SO answers
A coworker submitted a bunch of changesets to source control -- Can I just get the most recent one to get all of his changes? Or would I need to get each one individually? In other words, do changesets compound?
And more generally, what's the easiest way to ensure my local repo is identical to the server repo (minus the new things I'm working on).
I'm much more familiar with Git if that would help explain this
With your source control set to TFS in VS (Tools > Options...) just right click on your project file in Solution Explorer and select Source Control > Get Latest Version (Recursive). I do it twice just to make sure I get a message saying "up to date".
You can also use Source Control Explorer and get a specific changeset by right clicking the change set and selecting a similar option, and yes, these will get all changes up to the one you clicked.
Edit:
A little confused rereading your title it sounds like you want the server to match local, then your question is about matching your local to the server. So let me address both.
To get the server to match your local this would be most like a "Check in" (or 'push' in Git) this will merge your files into the server. You can perform a check in by clicking the Team Explorer tab and selecting "Pending Changes" then type a description and click "Check In". Where there are conflicts your will be notified and asked how to proceed, but in most cases following best practices this will not be the case.
Then you will want to match your local with the server (basically a 'pull' in Git) by right clicking the project file and selecting 'Get Latest Version (Recursive)'
Hope this helps.
Related
TFS 2018 was offline only for a day and I only made a couple of changes to a 7 project solution (most of the various projects are base projects like models, repositories, interfaces, etc.)
I had to overwrite files to continue because apparently they were read only. Anyway, I'm going back online today and I'm afraid to checkin my local changes because it shows I've changed nearly 80 files which is impossible, I only changed like 2 or 3 files.
Should I check them in anyway? I'm afraid I'll mess up something!
According to your description, seems you are using server workspace (files are ready only).
Work offline with difficulty and with poor performance
When you are offline in a server workspace, you cannot work with your
local files because they are read-only until you check them out. You
can check out files only from Solution Explorer, and only after you
switch to offline mode (as explained below). While you're offline, you
can't perform any other operations, such as add, delete, rename, or
undo.
Source Link
To edit a workspace, you can specify whether its location is Local or Server. Local Workspaces which could work offline easily. You can quickly begin editing a file when your network connection is unavailable or unreliable. From Solution Explorer you can add, edit, delete, rename, undo, and compare items in your workspace even when you're not connected to your Team Foundation Server.
Edit the workspace and choose advanced, you could see the Location of workspace type.
In your scenario, you could do a diff using Beyond Compare or something to see what changed.
If nothing changed, check if you are using the same workspace. You may select another workspace than you used.
In Source Control Explorer, check if you choosed the workspace the workspace you were work in.
If all above not work, you could also try this workaround, select all the files in "Pending changes" window and activate the context menu. Then click "Undo..." > "Undo Changes" > "No to All".
The files without changes will be rolled back. More details please take a look at this question: how to undo pending changes of files that are unchanged?
I am new to using TFS source control.
I have a large project which I have been porting from SVN. I am checked in and up to date with all projects. However, I opened up Visual Studio today and all project items are in the pending changes included window even though there are no changes.
I haven't touched or edited any of the files for my TFS files since last time.
To verify, I used Araxis Merge to do a folder comparison and can see that no actual changes have taken place.
Why are these unchanged files appearing in my check-in window?
Here is an example of a diff in visual studio from the previous version:
I can't see anything!
Hopefully this shows my local workspace
When you create or edit a workspace, you can specify whether its location is Local or Server. Local Workspaces are TFS's attempt at DVCS and actually gives you a much more SVN-Like experience.
Edit the workspace and choose advanced, you could see the Location of workspace type.
Maybe formatting, line endings, encoding. Do a diff using Beyond Compare or something to see what changed.
If nothing changed, check if you are using the same workspace. You may select another workspace than you used.
In Source Control Explorer, check if you choosed the workspace the workspace you were work in.
If all above not work, you could also try this workaround, select all the files in "Pending changes" window and activate the context menu. Then click "Undo..." > "Undo Changes" > "No to All".
The files without changes will be rolled back. More details please take a look at this question: how to undo pending changes of files that are unchanged?
Is there any recommendable solution to integrate SVN with TFS 2013 in a sense that SVN is being used for source control and TFS for work item tracking?
For example, it should be possible to link commits in SVN to work items in TFS.
You can use Integration with Bug Tracking Systems / Issue Trackers: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html
It is very common in Software Development for changes to be related to
a specific bug or issue ID. Users of bug tracking systems (issue
trackers) would like to associate the changes they make in Subversion
with a specific ID in their issue tracker. Most issue trackers
therefore provide a pre-commit hook script which parses the log
message to find the bug ID with which the commit is associated. This
is somewhat error prone since it relies on the user to write the log
message properly so that the pre-commit hook script can parse it
correctly.
TortoiseSVN can help the user in two ways:
When the user enters a log message, a well defined line including the
issue number associated with the commit can be added automatically.
This reduces the risk that the user enters the issue number in a way
the bug tracking tools can't parse correctly.
Or TortoiseSVN can highlight the part of the entered log message which
is recognized by the issue tracker. That way the user knows that the
log message can be parsed correctly.
When the user browses the log messages, TortoiseSVN creates a link out
of each bug ID in the log message which fires up the browser to the
issue mentioned.
Go through mentioned URL for detailed description.
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html describes how to configure folders in TortoiseSVN to do a one-way integration between file versions committed in TortoiseSVN, and work items in TFS. When a developer commits the file version, he/she is prompted for the TFS work item number (which works fine if the developer knows the number). It even creates a link to the TFS work item in the Revision Log of the file in TortoiseSVN. However, it does not display a list of work items for the developer to choose from, nor is there any link in the TFS work item going back to the committed file version in TortoiseSVN. (It is possible to write an issue tracker plug-in for TFS to do this, but all the plug-ins I have found on the internet seem to be for older versions of TFS.)
This integration will insert the bug number into the Revision Log of committed source files, and will add a link from the log to the selected bug in TFS. Although you make this change inside your working copy, it will apply to the same folder in other working copies once those working copies have been updated.
To associate a folder tree in TortoiseSVN to TFS:
1. Right-click on the folder in your working copy. This should be at the apex of the folder tree you want to associate with a project in TFS. Select TortoiseSVN > Properties.
2. On the Properties - TortoiseSVN window, check to see whether there are any bugtraq properties for this folder. If not, click New > Bugtraq (issue tracking integration).
3. The Edit Bugtraq Properties - TortoiseSVN window opens.
a. For Issue tracker URL, specify the URL to your work items:
http://tfs_server_name:8080/tfs/DefaultCollection/TFS_Project_Name/_workitems?id=%BUGID%&_a=edit
b. Next, place a check in the "Remind me to enter a bug-ID" checkbox.
c. For Message Pattern, specify something like:
TFS Work Item: %BUGID%
d. For Message Label, specify something like:
TFS Work Item:
e. For "Bug-id is", specify Numeric.
f. At the bottom of the window, place a check next to "Apply property recursively". Click OK.
4. Back on the Properties - TortoiseSVN window, verify that the bugtraq properties have been added and click OK.
5. Remember to perform an SVN Update and SVN Commit on the folder after changing its bugtraq properties.
The bugtraq properties that implement this one-way integration between SVN and TFS are built into Apache Subversion and so should work for SVN even if you are not using the TortoiseSVN user interface.
My team and I started a project at Azure and we have a git as the VCS/SCM.
One of my partners had made a few changes, and he had commited them. When I try to get those changes at my local repository, and I press sync at the Visual Studio, the following message appears
Cannot merge because there are uncommitted changes. Commit or undo
your changes before merging again. See the Output window for details.
The output window shows the message below
Cannot complete the operation because of existing changes to the
following file:Project\Project.csproj
I have searched everywhere at google, but I did not find anything similar.
Can anyone help me with this?
We are stack.
Thanks a lot
It probably means VisualStudio automatically added some references to the file ProjectProject.csproj, where it keeps general project settings. In VisualStudio 2013 you may do:
Go to the TeamExplorer
Select "Changes"
Search through Included and Excluded Changes, .csproj file is probably there
Right click on it and select compare with unchanged to see the differences
Now choose to commit it or undo the changes (if, for example, the changes are not necessary) to be able to sync with the current repository.
I had this same dilemma and it turned out that somehow the file that was preventing me from switching branches and was in my solution, was not being tracked like the other files were. I just added it to source control via the explorer window, committed and pushed it, then I was able to switch branches just fine. Hope this helps.
Are there any good techniques to help us know which branch (or trunk) our working copy is from? We recently converted to Subversion and we're using release branches. I had two developers commit changes to the release branch that should have been committed to the trunk. We're using CI (TeamCity), so I recognized the problem right away and was able to revert the changes but I'd like to prevent it from happening again. From within Visual Studio, especially, it's easy to make a mistake and commit to the wrong branch.
We're using TortoiseSVN and AnkhSVN.
Edited to add:
Just to clarify, I'm looking for a method to prevent careless mistakes, I already know how to find this information. There are two careless mistakes I'm trying to prevent:
Doing work on the wrong branch. If this is caught before commit, the developer has to merge the changes back into the correct branch.
Committing to the wrong branch. This combines the pain of point 1 with having to revert the changes in Subversion.
Edited to add: We just made the switch to the VisualSVN VS plugin and it has a toolbar that displays the path of the current working copy. I really like the reassurance that I'm working on the right branch.
Perhaps you should consider using a pre-commit hook: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html
Then you could do something like only approve checkins that have 'for release' in the comments for that particular branch or something like that and return an error message otherwise.
In AnkhSVN (in Visual Studio) the project url of your working copy is from is displayed in the 'Working on' field of the Pending Changes Window (View->Pending Changes).
The url of a file/folder is also displayed in the Visual Studio project window when you select a file in the Pending Changes Window or Working Copy Explorer (and in many cases even when you select a file in the Solution explorer; but this depends on the project type).
[Update: I just added AnkhSVN issue #581 for extension of the commit dialog.]
Tortoise SVN adds columns to the Windows Explorer view. In "Details" mode, right-click on column headers to get a list of available columns, at the bottom, select "More" to get a dialog of all available column types.
SVN short URL should quickly show you what the location is in the repository.
But this doesn't appear to work under vista ...
Right click the folder, move to the subversion tab, there it says the project it's linked to.
Also, in the commit dialog, it says so at the top of the dialog.
From the working directory:
svn info
URL will contain the branch your working directory points to.
<EDIT> Seeing how many people dislike the command line, the closes thing I found from TortoiseSVN is the "repo browser" which seems to use the selected branch as your starting path in the repo. </EDIT>
Avoid re-using working copies. If you're working on 2 places in the repository, have 2 working copies, named appropriately, like: Project-trunk, Project-release.
Here is a simple idea which might help:
Create an empty text file named "branch_XX" (or any name) and add it to your branch.
commit this and then when you switch to the trunk, the file will not appear in the solution explorer.
It sounds stupid... but it does the trick.
I really hope they will add something that might mark what branch we are using without going to other windows.
In AnkhSVN (in Visual Studio), right click on your project/solution, then Source Control -> Subversion -> Select in Repository Explorer. It will automatically select the branch you're currently working on (i.e. the branch you're switched to).
I don't think that the accepted answer for AnkhSVN works for Projects, since I always see the same URL in the "Pending Changes" even after I use the option "Switch Project" on a project.