I'm working on a project where I need to have a few branches of the same source code open at the same time. Is there an easy way to tell at-a-glance what branch I'm looking at on visual studio. At the moment I'm inspecting the properties of a source file to view the path in order to identify the branch.
There must be a better way - how can I tell at a glance what branch I'm looking at?
Try the VsCommands extension. It shows the current branch in the solution badge in the taskbar, and the title bar. I am using mercurial and it seems to work well with that.
Use the free Branch Info TE Extension (BITE) for VS2013:
https://visualstudiogallery.msdn.microsoft.com/33a5274b-271b-45dd-8dc5-734d927a19dd?SRC=VSIDE
If it's exactly the same code - what's the point in it?
If it's not, maybe use different named projects inside the same solution?
BTW, you don't have to change default namespace with the project name, so it should be relatively easy to do.
Then there's another way - hover your mouse pointer over the file tab, you'll see the file path almost immediately. I do that every time I work on new version, but checking something from the old version.
If there are only 2 versions - you can use 2 monitors. I put the old (less used) version on "side" display, and current (most changed) on "front" one.
Related
Context
I am using VS 2015 and TFS as my version control. I do know how to get a history for a particular source file, and also know how to see in editor the picked version of that file.
Question
In the current version of a particular file I read a comment say
// This is a comment
I would like to find in which commit was that line committed. The obviuos solution is opening history, then the different versions of that file starting from initial commit, and searching for the text in the editor window until a looked text is found.
Is there any convenient solution for that?
Right-click inside the open file in Visual Studio, on the interesting line, and choose Source Control (bottommost menu) and then Annotate.
You'll see the file with changeset information along the left edge.
Note that this will only easily give you access to how the current file came to be, if you wish to dig through annotated historical versions it becomes a bit more cumbersome.
I have shelved my file, test.cpp and continued working on it. Now I would like to see what additional changes I've made to test.cpp since I made my shelf.
Let's say that after I checked out test.cpp, Bob checked into tfs an update to test.cpp.
Let's make some nomenclature to help:
source_version: the original version I checked out and started working from
latest_version: the test.cpp Bob checked into tfs, the latest version after I started working on test.cpp.
shelf_version: the test.cpp in my shelf, a modification of source_version, lacking Bob's addtions (i.e. not merged).
local_version: the test.cpp that I have on my local disk "local_version", that started from source_version, and has addtional work beyond shelf_version.
Using this set of labels my question reworded would be:
How do I compare local_version with shelf_version.
My options:
In Pending Changes pane, I can
Compare with Workspace Version
This is wrong, this compares local_version with source_version
Compare with Latest Version
This is wrong, this compares local_version with latest_version
In 'Shelveset Details' pane view of the my shelf
Compare with Unmodified Version
This is wrong, this appears to be the same as comparing shelf_version with source_version. Which is odd, this function is already handled in the next compare
Compare with Workspace Version
This is wrong, this compares shelf_version with source_version.
Compare with Latest Version
This is wrong, this compares shelf_version with latest_version.
Thanks
It is really irritating that MS hasn't fix this yet. A workaround that I am currently using is an external diff app and doing the following:
Open your external diff app.
Go to your VS environment and go to the Team Explorer pane and bring up your Shelveset Details.
Bring up the context menu on the file you want to compare (right click or menu key).
Select Open. This'll DL the file to your local system as a temporary file.
Bring up the context menu on the window tab right above the file contents which states the filename and select Copy Full Path.
Go back to your external diff app and paste that file path as the first one you wish to diff.
Go back to your VS environment and open your copy of the same file.
Bring up the context menu on the window tab right above the file contents which states the filename and select Copy Full Path.
Go back to your external diff app and paste that file path as the second one you wish to diff.
Now diff the two files.
I know this is a lot of steps to do something that should be a simple (maybe 1 or 2 click) operation.
If you want MS to get off their ass and implement this feature, you might want to vote for this feature here.
I repro all you steps and you correct that you can't compare the shelf_version with the local_version with the VS compare. I use Beyond compare and when the compare start it lists the left and right side. So I changed the left side to point to the local folder and I could see the outcome you are looking for.
I'm using Visual Studio 2010 with VisualHG and TortoiseHg. I've noticed that if I move or rename a file using the Solution Explorer, a little [R] appears next to the file, which I assume indicates "renamed". However, if I go to commit my changes in TortoiseHg, it doesn't perform a rename--it deletes the old file and adds the new one. This causes all the history for the file to be lost (and bloats the repo unnecessarily).
Is there any way to get this to work properly? There's really very little benefit to using VisualHG if it's not going to coordinate file renames properly with TortoiseHg.
Also, I should mention that TortoiseHg has a "Detect Copies/Renames in Solution" dialog, but I can't seem to get it working. First, I can't seem to find any button or menu item in the TortoiseHg Workbench to launch it. Second, if I launch if using the terminal by entering thg guess, no path appears in the Unrevisioned Files box (and there's no apparent way to add one). I made sure I was navigated to the correct directory (my solution directory, which contains my .hg repo) when I tried this. I also tried thg guess solution_directory_path, but that made no difference. If this dialog is a possible solution to my problem, how do you actually use it?
Edit
I finally figured out that you can access the "Detect Copies/Renames in Solution" dialog by right clicking the solution folder in Windows Explorer, and selecting TortoiseHg > Guess Renames. When I do this, however, again, no path appear in the Unrevisioned Files box, so I still can't get started with this dialog. (I.e., I can't even perform step 1 in these instructions.)
Edit 2
I found a bug report on the VisualHG CodePlex issues page that I think explains the problem I'm having: https://visualhg.codeplex.com/workitem/99. I'm kind of surprised it hasn't gotten more votes, though.
After further investigation, I realize that, even though the files were shown as removed/added in TortoiseHg Workbench, they in fact were renamed correctly.
If you click a file with a "+" next to it in the Workbench, if that file was in fact a rename, the header for the code window will show something like this:
Project/Folder/RenamedFile.cs (renamed from Project/Folder/OriginalFile.cs)
After reading a bit more about what Mercurial is really doing, it sounds like it actually is deleting and adding, it's just that the added file maintains a reference to the original, so you can still view the history across renames.
I'm not sure if this explains the problems I was having with "Detect Copies/Renames in Solution", but I'm now satisfied that renames are being handled properly.
When I make edits to file, TortoiseSVN will show an indication on the folder that file belongs to that there are changes pending to child items. AnkhSVN only shows (red tick) changes to a project when files are added/removed (because the actual content of the project file in this case has changed)
Can you make ankh give any indication at the project level that child items have been edited?
Unfortunately, no. Ankh only shows an indication on modified files, whereas TortoiseSVN can traverse folders recursively and mark those with changed files within them.
If you desperately need this feature, you can try out VisualSVN plugin. It tries to mimic TortoiseSVN behaviour as close as possible. In fact, it uses TSVN dialogs for operations such as Commit or Update, for instance. When you modify a file within a project, it highlights the file, the project this file belongs to, as well as the solution node in the Solution Explorer.
Unfortunately, it's not free (US $49 per seat), but IMO it is worth its price.
The recommended way to see what changed globally in AnkhSVN is the 'Pending Changes' toolwindow. This shows you all interesting files in a single view and allows you to operate on them easily.
You can open the toolwindow via View->Pending Changes.
Try this:
Right Click the File -> Subversion -> Lock
This places a lock on the file so that others cannot edit it.
When you commit, it should unlock the file.
If it does not, Follow the same steps and select Unlock.
Edit: I use AnkhSVN for my svn but it's just me that uses it. If a corporate environment I mainly use TFS which does the same thing (lock/unlock) but it does not allow others to check out.
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.