I have a solution working on a specific version of an input file, and want to parallel work on a branch on a new version of this file.
In this new version, certain logic projects aren't being used anymore, and therefore I want to remove them from the solution.
When I create the new branch and delete these projects in visual studio they are still showing up on Azure devops. When I check the initial branch out I need to manually add them back to the solution.
How do I let them work independently, so when I change branch these projects are not being used anymore and then added again?
Related
I recently started working on a different branch of my repository, but I noticed that I had not merged my work from an earlier branch yet. I figured I could copy and paste the missing pieces over from one branch to the other but I'm not sure if I can open them in parallel in two separate instances of Visual Studio.
I believe you can still merge your previous branch into the one you are working on?
If you really really need to have both versions open at the same time, you could clone the same repository into another, seperate, folder and have the previous branch there and open that version of the project.
I'm a rank novice in Azure DevOps and I was using a local coding project in VS 2019/Team Explorer to learn about GitHub, Azure, version control, pipelines, PRs, etc. I created a project, added files and, for quite a few months, I thought I was getting the hang of it. A bit of overkill, but it was worth the learning experience.
Then a few days ago, after a month's hiatus, I returned to complete work on a local branch and nothing seemed to work correctly. I can't recall what errors initially appeared (I attempted way too many "solutions" without really understanding what I was doing) but edit conflicts showed up, I couldn't sync, pushes didn't work, and nothing I could think of would allow me to resynchronize (not in the Team Explore sense) with the remote repo. Edits I make in local files no longer show up as Changes in Team Explorer ("There are no unstaged changes..." despite my editing files, no "Commit" or "Stash" command is enabled).
How do I wipe the project's repo slate clean in Azure? I just want to start over, learn from my mistakes and carry on fresh.
I would like to establish a new baseline, if you will, clear all the branches, commits, PRs, and the work items. I would like to keep the Project settings, the Overview (Summary, Wiki, Dashboard) and possibly the pipelines.
Do I need to create a new project?
Any advice would be appreciated.
For the issue in Visual Studio:
You could try to re-connect the Project in visual studio and clone the Azure Repo to a new Path.
In this case, you can get the latest Azure Repo content again. Then you could make changes in local and push them to azure repo.
For the requirement: establish a new baseline
You don’t need to create a new project. You can directly create a new repo in the current project and push the files to the new repo.
Here are the steps:
Step1: Navigate to the old repo and select the branch that needs to be moved to the new repo. You could use the “Download as Zip” option to download all files to local machine.
Step2: Create a new Repo in the current project.
Step3: Unzip files on local machine. Connect to the new Repo in Visual Studio.
Then you can add all files as changes to push to azure repo.
The new repo will have no old branches, PRs and commits. But other parts will not be affected.
Hope this helps.
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
I have one Project in SonarQube with some history and some Confirmed Issues and I need split this project, because of two versions of source code, but I need the history and Issue changes in both projects. How to do this? It is possible somehow clone, duplicate existing Project to another one with different name?
Cloning or duplicating a project is not supported.
You can use the Time machine functionality of SQ to "recreate" the past analyses of the project under another name but it won't recreate the history of changes on issues.
We are currently running multiple branches within TFS 2013:
Development
Release
Trunk
etc.
Each branch has an automated test build. The purpose of these builds is to publish the latest code (and database changes) for each branch to our test server for manual testing. We maintain a separate IIS application for each branch so that different versions can be tested simultaneously.
Each branch has unique .csproj, .xml profile and web.config settings which control which application and database each branch deploys to, which works great.
However when we merge from one branch to another, auto-merge replaces these branch specific settings causing us to deploy our test builds to the wrong URL and database.
I am aware that auto-merge can be completely disabled in Visual Studio settings but is there a way we can continue to use auto-merge except for specific files?
Any suggestions welcome
This is a well known problem with any code promotion model. I would suggest that you move instead to a binary promotion model.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
With a binary promotion model you build the bits once with replaceable parameters and create or use a tool that orchestrates the release and feeds it with the correct variables for each environment.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
I recently built out an end to end scenario using VSO. You can see in the post the passing of the values for each environment.
The software industry is moving towards continuous delivery and continuous integration. Neither of which is possible in a code promotion model.
You could disable auto conflict resolving during merge, but in this case you have to resolve these conflict manually (ignore)
Options -> Source Control -> Visual Studio Team Foundation Server
Attempt to automatically resolve conflicts when they are generated
or you could use tf.exe for merge:
tf.exe merge /discard CS
use a changeset which will be always discard from merge.