I have this branching structure in TFS 2013.
Now I had a folder already in my Main branch called Websites.
I added a project TestProject in my Dev branch under Websites folder.
Now when I merge Project from Dev to Main branch, it shows these in the pending Checking window.
There is [merge] next to Websites folder. I get that I am merging some stuff into Websites folder.
But for all other folders and documents I have in the project I added, it shows [merge, branch] above.
What does that 'branch' indicate and what is it's importance? Am I doing something wrong there?
If it just shows [Merge] then there was a previous relation between the source and the target file or folder.
If it shows [Merge, Branch] it means that a new relationship has been created. This was most likely a new file or folder in the source branch.
Related
I am a bit confused about the concept of workspace and working folders. I see in the Source Control Explorer I can setup multiple workspaces on my machine. My understanding of workspace is basically a folder that contains all of my projects (even unrelated ones). For example, C:\Projects
I currently have a single workspace that is called the name of my computer which points to a directory called C:\Projects that has several projects in it that are each their own project on visual studio online. For example: DESKTOP-43DDV90P has a working folder for each project inside of it.
WORKSPACE: DESKTOP-43DDV90P
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
I would like to know if this is a correct assumption OR if I should be creating a workspace per project like the following:
WORKSPACE: PROJECT1-WS
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
WORKSPACE: PROJECT2-WS
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
When I finish setting everything up with a new ASP.NET Core web application under source control my directory structure looks like the following:
C:\Projects\Project 1
this contains:
Project1 (folder vs creates for solution)
BuildProcessTemplates (folder from vs online)
C:\Projects\Project 1\Project1
this folder contains:
Project1 vs solution file
Project1 (folder that finally takes you to the project1 site files)
A TFS workspace is basically an account between your computer and the TFS server. It contains a set of ServerPath -> Local Path mappings, and some settings about how the workspace is maintained (e.g. permissions, file timestamp behavior, etc).
Often when working on a project you'll end up creating branches. This is when workspace mappings become relevant. If you don't have branches, then you'll usually just want to map the entire codebase - i.e. you want all of the sources. But when you do have branches, often you'll want only one branch at a time. For example, if I have this:
You can see how each branch contains the same set of files. If I'm developing something in the FeatureX branch, eventually I will merge it into the Master branch.
This is when your question becomes most relevant: do I have a workspace that contains both of these, or do I have separate workspaces for each branch? This is a matter of preference. I prefer to have separate workspaces, because it avoids the case where I've made changes in multiple branches and only want to check in changes to one of them. For example:
I might not notice in a larger project that I have modified files from two different branches. TFS does allow this, but usually when I'm working in one branch I don't want to affect another one. Another issue that can occur is that TFS sometimes has issues when merging changes if one of the included changesets spans multiple branches. For example, say I check in the pictured change; then I create a new branch (Feature2); then I merge the changeset into Feature2. What should happen? Does it take the copy that I checked into Master or into FeatureX? You can make this work, but the point is that you can also fall into some weird situations. With multiple workspaces, I would only ever see changes for the branch pertaining to that workspace:
That’s depending on your situation, company policy etc… It’s hard to manage if there are too many mapping in a workspace, if not, a workspace is ok.
Some articles about optimize that can help you:
Using multiple workspaces with Visual Studio
Optimize your workspace
I had a solution containing the following projects:
Web App 01
Server Control Foo
Server Control Bar
Each project has its own directory in the root of the solution directory, directly mirroring the structure of the solution.
I branched the solution, then combined items 2 & 3 into a new project within that solution, then deleted projects 2 & 3. I committed the changeset. The resulting structure in VS2015 solution explorer was this:
Web App 01
Server Control Library
I then merged the branch, and committed this also. Over time, branching and merging has got slower and slower. On inspecting the file structure of my hard drive, and Visual Studio Online, I see this folder structure:
Web App 01
Server Control Foo
Server Control Bar
Server Control Library
Despite Solution Explorer not listing the deleted projects, the folders and files from all my deleted projects remain. Despite their status, they are also being branched every time. Is this the correct behaviour, and is it safe to delete them? If so, should I delete using VSO, Windows, or VS2015?
I assume you are using TFVC (changeset, branched the solution).
First, delete the projects from solution (right click the project in VS > Remove) just remove the relationship between projects and solution, the projects’ files and folder are still existing in the hard drive. So you need to delete these files and folders from hard drive (file system).
Secondly, these files are still existing in the source control too, because they aren’t marked as deleted if you just remove projects from solution, so check in changes just affect the solution file, it won’t delete files from source control. So you need to delete them from source control and it’s safe.
Steps to delete files:
Go to Source Control Explorer in VS
Right click Folder or file > Delete
Check in changes
BTW, the files still can be restored if you don’t permanently destroy them. (Destroy command), more information, you can refer to this article: Delete or restore files and folders in Team Foundation Version Control (TFVC)
Somehow, my Visual Studio project got very much messed up. The source code was good, but things were messed up in some of the configuration files. After hours of fighting with it, I found an earlier changeset (changeset 20) that compiled and ran fine, albeit without the latest changes (I was up to changeset 25 by now).
I then performed the following steps:
I retrieved a copy of changeset 20 into a new temporary workspace.
I used WinMerge to manually merge the latest source code changes into the changeset 20 code that was in my temp workspace.
I branched my main branch (called MainBranch) in TFS to a new branch called TempBranch.
I manually copied my merged files (from step 2) from the temp workspace into the main workspace for TempBranch.
I checked the merged code into TempBranch.
My Heirarchy looks like this now:
So, now, TempBranch has all the latest "good" code, and none of the corrupt configuration files. MainBranch has the bad configuration files.
So now that TempBranch is exactly how I want it, and it's what I want to base all further development on, what should I do at this point, so that MainBranch is basically identical to TempBranch?
I'm worried that if I try to merge the branches, it will try to merge the bad config files in MainBranch with the good ones in TempBranch. I want to make sure that for all differences in the two branches, the TempBranch version "wins".
You can try to merge from TempBranch to MainBranch, and take source branch if there are conflicts.
If the history is not important in MainBranch, you can reparent the TempBranch, and choose No parent. Then there is no hierarchy between TempBranch and MainBranch, you can work on TempBranch.
I have a ASP MVC project committed to SVN (used Visual SVN).As the project grew up i kept adding files.Most of the time when i "Get" project everything is available in VS2012. But today when i get the complete solution from repository - some of previously added files(cs and cshtml and respective folders they are in) are not included in project solution in VS explorer but they are there in the Directory that i did get from svn-
My Project in SVN~
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
Now i add a new folder to viewfolder with files within and commit
MyMVCProj
ModelFolder
ControllerFolder
ViewFolder
view1folder~hasfiles
view2folder~hasafile(<=This available in my disk after getting from svn not in VS2012)
what am i doing wrong? I do get project everyday by >Visual Studio2012>VISUALSVN>Get Solution from Subversion;this saves project to disk and opened in VS
I guess that project's file wasn't committed to the repository together with other changes. Here is how you can solve this:
Go to Visual Studio | VisualSVN | Show log and look for the revision committed by DEV2 which added view2folder/,
Take a closer look at changed paths. Most likely the revision added view2folder/ with its contents but the revision didn't change MyMVCProj.csproj file.
The *.csproj file contains information about the files included in that project. When items are added to the project, references to them get into *.csproj file. If the file is missing these references, then you don't see added items in Solution Explorer.
In Solution Explorer, click Show All Files, right click view2folder/ and choose Include in Project.
In VisualSVN's Pending Changes dialog you can see that project's file has been modified. Commit the change.
That's it.
I found solution after some workaround -
When two or more person working on a project this situation may occur. For me it happened because of following scenario:
Dev1 commits projects to SVN,
Dev2 GETs it and does something and even adds files/folders,
Dev1 just updates and starts working. Now the newly created files by Dev2 are not included in project; but they are available on local disk. These had to be manually added to project after update. (Look for related post).
Please Update here if my approach is wrong.
For one of my ASP.Net site I use AnkhSVN to commit to a VisualSVN Server with a post commit hook to update the live website.
This setup works great for every directory EXCEPT the Bin directory. When I build my solution the dll is placed in the site's /Bin but does not show up in Pending Changes. If I select the dll, right click -> Refresh Status, right click -> Commit... it will be committed, but I cannot commit the dll's in the /Bin with the rest of the site.
What am I doing wrong?
Visual Studio does not regard the dlls referenced in the project, as source. Thus they will never be checked in, only copied to the bin folder when the site is built.
VS uses the .refresh files to know which dlls are referenced (the content of a .refresh file points to the original dll), and these refresh files are regarded as source and will be checked in. So to make your setup work you will need to build the project before deploying the site.
Imo this kind of task belongs in a build system, like CruiseControl.Net or TeamCity, not in a svn post commit. You can easily set up such a system to monitor your svn repository, have it compile the solution and then, upon a successful build, publish to the live website.
Actually, I would advice against automatically publishing directly to a live website without first publishing to a staging server for test. But you could have your build system do that too.
Check if the files in your your bin folder are even under version control (you can do an svn add if not). Another possibility is that the files in the bin directory are being ignored by subversion. In that case, you'll have to remove them from the ignore list.
AnkhSVN doesn't look for libraries and some additional files!
But you can add additional files into SVN in hand mode:
Coose View -> Working Copy Explorer
Find files that you like to add, and click Add:
Press ok!
And now you can see you library in "Pending Changes" window.
Agree with Nader. Perhaps files are not under source control. Also Suggest you dont include the bin files (as they are really build items) in source control. It is sufficient to have the source code under version control and tag it appropriately once the build is done so you can reproduce the necessary binaries as and when required. If you MUST have the built packages tagged and versioned, then you can run svn status on the build workspace -- it will show up all the files not yet included under source control and you can write a small script to add them all after.