Our company is migrating from VSS to SVN as part of an upgrade from VS2005 to VS2010. I am evaluating the VisualSVN implementation – VisualSVN Server looking after the repository, and using VisualSVN Client inside VS2010. Our work is predominantly Web Application Projects.
I am having real problems merging a branch back to the trunk
Here is the scenario (all SVN actions being performed with the VS2010 VisualSVN plugin):
In a given WAP, I have created a branch from the /trunk called /branches/test and configured it to run under local IIS in VS2010 with the branch held on my HDD away from the repository (which is on a server)
I’ve edited the homepage in /branches/test to add HELLO WORLD to the WAP’s default.aspx and committed it to /branches/test
I can verify through the VisualSVN browser, that the trunk version doesn’t have the HELLO WORLD, but the branch one does
I now switch to the trunk in VS2010 I get a warning “There are changes in the working copy. It is recommended to commit or revert them before switching” – an additional commit just tells me nothing has changed (which is right) so I continue
Now in the trunk, I confirm there is nothing to commit just to be sure
Still in the trunk, I select “Merge…” followed by “Reintegrate a branch”, set the From URL as [path]/branches/test and the Merge Depth as “Working Copy”
I get an error, “Cannot reintegrate into a working copy that has local modifications".
Have I got something fundamentally wrong in my understanding of branching here, is my process flawed along the way or is this a feature of VisualSVN?
Thanks
Sounds like a bug in this VisualSVN client thing. Normal Subversion doesn't behave like this.
I've found the problem - it was versioning the solution file, which wasn't showing in VS 2010 by default. Therefore I did have uncommitted changes on the local working copy which I wasn't aware of (the solution file).
I'm not sure of the best way forward here. Should I exclude the solution file (.sln) or version it? My worry is that if it's excluded and I add a project in a branch and merge back to the trunk, when the next person branches from the trunk will they run into problems (as the solution file in their own working copy will not include the new project)?
(I'm new to StackOverflow - should this be posted as a separate question?)
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.
Our team started using TFS few months back and we are learning as we progress. We first checked in our existing code to TFS thereby creating a Main Branch. We then created a Development Branch from this Main branch.
We just did a release and I merged Development branch with Main. It asked me to map Main branch folder on my workstation. Done that Merge completed successfully. But after merge I noticed on server that change sets are still old and source code on server has not changed.
looking further I noticed that the changed file is marked as 'merge pending'.
When I opened solution from mapped folder of main branch, I did see that all changes from Development branch merged to Main are in pending state.
Questions
Do I always have to check in pending changes after each merge in TFS
Is is possible to merge source code on server instead of from
workstation (All code in development is in Checked in state).
I am using VS2012 (if that matters)
Please advise, especially if I am taking a wrong approach with TFS.
In answer to your questions:
Yes, you always have to check in pending changes. Pending changes are local to your machine, they give you the chance to review the result of the merge locally before they are committed to the server. This is especially important because the merge may result in a conflict that you need to resolve before you can check in.
I don't think that this is possible (although I never researched this specific question). This is, again, because of the possibility of a conflict that needs to be resolved manually. Even if you perform a merge programmatically via the TFS API, the merge will happen locally.
Don't worry, you are doing the right thing. Only one word of warning regarding merges in general: Before you attempt a merge, always make sure that you perform a "get latest" operation on the target branch! The source branch does not need to be up-to-date on your local machine because the merge operation will get the source branch data from the server. But the changes will be merged with whatever version your local target branch files have, so if these are not up-to-date you will get unexpected results.
Overview
I am using VisualSVN in Visual Studio, VisualSVN Server on Windows, and of course, TortoiseSVN. I wanted to know what the best method of sharing multiple projects over multiple solutions was, and if there was a better method.
Layout
My Repository kind of looks like this (not their real names):
Library.Common
Library.Web
Library.DB
Library.CMS
Customer1.Site
Customer2.Site
Process
To create a new site that contains common projects:
Create Repository in SVN-Server, e.g. "Customer3.Site"
Create Web site using Visual Studio 2008, named "Customer3.Site", VisualSVN used to commit to the repository created in step (1).
Edit properties of Customer3.Site and specify the necessary projects as svn:externals, e.g. "Library.Common", "Library.DB", etc.
Perform an update, to get these external projects, and add them to my solution in Visual Studio, add the necessary references to the Customer3.Site web project and hit build.
So far so good.
The Problem
All this works fine, I am happy that if I have to modify any of the core Library projects I can do so right in the same environment and commit them to the repository. As more and more customer sites are built, I will then have to keep track of what I've done and remember to SVN Update and rebuild those sites which seems quite a long-winded task.
Is there a better way of doing this, a more best-practice solution? Am I breaking any fundamental SVN laws by doing it this way? I want to find a good solution that doesn't cost too much time and isn't overly complex either.
I've been facing a similar issue ... I am setting up a base install package for WordPress, something we would use to quickly get a site setup, it contains the core of wordpress + a set of baseline plugins, both third party and custom ones we've created. Everything pretty much comes from SVN.
Different plugins have different versions/tags and to setup an svn external pointing to a specific tagged version per project would be a nightmare ... only to then have to go into each and every project and do a property adjustment and then an update.
What going to be implementing is a vendor branch with specific versions as needed. All I should then have to do is update the client sites, since they will always be pointing to the latest versions (under my control in the vendor branches).
As to your problem, and also in my case: I would probably write a commit script to update all projects automatically when something in the vendor branch is updated.