Merging whole projects is a pain in VSS as the IDE only wants to let you do individual files. I have a situation where we created a new project (in both the VSS and VC++ sense) in a branch, and I then merged/copied this into trunk. All active development is still going on in the branch, the trunk version has no independent changes and this is likely to continue for some time as changes are made in the branch and then merged into trunk.
I wodnered if the easiest solution is simply to delete the trunk version of the project and re-copy the branch version each time, since it avoids the need to do any fiddly stuff and makes sure the trunk version is exactly the same as the branch at time of copying.
Does that seem reasonable or does it introduce problems I hadn't foreseen?
You may also try this: check out the trunk and use Reconcile All in Project Difference dialog box to reconcile the changes in the branch. Here is an article on VSS Project Diff.
Related
I am not sure of the right place to ask this question as it is about procedure as opposed to programming. If it can be moved to the right location I would appreciate it.
I am continuing to learn the concepts of version control and TortoiseGit. But I am not sure on a concept ...
I have project A.
I am working on FEATURE BRANCH X.
I am not finished with FEATURE BRANCH X just yet.
But I would like to go back to project A and make some changes.
Then come back to FEATURE BRANCH A and continue with that branch and eventually merge it to project A.
I am concerned about losing commits and / or files. It has happened before to me.
I have only used basic Git, but I am pretty sure that such feature exists in TortoiseGit as well, it's called stash. It helps you to save your changes without committing them to the branch. After you stash changes, you can go to any other branch and work there. When you return to the branch with stashed changes, you pop stash and now these changes are available as unstaged.
s/w versions:
TFS2008 server, VS2010, windows xp
I have the following branch structure in TFS
$/Root/Main Branch
$/Root/Dev/Project1
Project1 was branched off the Main Branch, few months ago. Now I need to merge the latest code in the Main Branch to the Project1 branch. During that time, some new folders were added to the Main Branch.(Main Branch/CoreDataClasses/..). So when I try to merge this new folder into the Project1 branch using the merge wizard, I don't see the Project1 branch in the list of target branches. Why is TFS not showing me my dev branch in the target branches list?
Do your merge from the root (where you branched), not the individual folder(s). Remember that merges aren't destructive until you check in, so you can choose to only check in the new folders if you want to hold off other changes.
With Tfs I've had much better experience merging from branch to the trunk and I think this might be the case here. Of course this might take a rethink of your strategy but it's doable.
I know this may be way offside but if you're doing cross branch merging a lot then definitely consider a distributed version control system like mercurial. I've used Tfs lots and really like it but when it comes to branching and merging it is a distant second to hg merge (mercurial command)
The folder structure between source and target have to be the at least 80% the same. If there was too many restructuring of the folder layout then I suggest you use the cmd line Merge with the force switch when doing the merge. See "Merge Command".
How do you handle versioning in a continuous integration environment where there is a development branch and a release branch? I'm using git so there is no incrementing repository version to use. Seems like there will be overlapping versions such as 1.1.0 on the dev branch and 1.1.0 on the release branch. Do you just append the text "dev" or "release"?
Also, when you create a release branch do you immediately increment the development branch to the next "proposed" release number? You may not know the next release number yet but if you don't increment it then you have 1.1.0 dev containing new work not included in 1.1.0 release.
So my main question is what is the relationship in the versioning sequences between these two branches?
Keep in mind, I'm not asking anything about how to decide what version numbers to use. I tried asking this before and kept getting comments like "increment major for breaking changes" etc.
I don't version the dev branch. The devline is the trunk and I periodically branch from dev to a new release folder. So the release branch is full of folders which are basically snapshots of the devline.
IE, under root I have /dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.
I'm not sure if this really answers your question.
I would recommend set a final activity for your CI environment to make tags. I believe the git command looks like this: git tag -a name
We use Major.Minor.Release.BuildNumber
though some places use Major.Minor.Release.CheckinNumber
So, if you want to use that then I would version your dev branch, otherwise just version the release branch.
If you have only one development branch, it is more effective to make it be the trunk and branch off a release branch every time you just want to stabilize for release. If you have multiple feature projects, you can have a branch for each of them with CI setup on those. Once they are done, you merge them one by one to the trunk and once all are merged, you get to the first scenario, where you branch a release branch off of the trunk again.
In any case, you don't keep the development branch going between releases. You want to end it and start a new one for development for the next version. This way some of the features can be branched off during several releases if they take longer. But also you don't have too much mess on your development branches.
You can branch the development branches for the next version as soon as you branched the release branch or even before if you chose to, but it is generally good idea once you stabilize for release, merge the changes from release branch into trunk and from there into the development branches if you do that. If you wait with branching off after release, you avoid few merges there, but you slow down development.
For personal projects I use Git for SCM, but at work we use TFS. One thing that I like about Git is that it allows a person to easily squash all the changes made in a branch when pulling the changes back into the master branch.
The benefit of this is that if their is anything wrong with the changes they can easily be removed be reverting back to the version before the merge even if no tag was created.
Is this. or the equivalent possible in TFS? Is this where shelving changes fits into the equation?
Thanks.
Performing a merge in TFS results in a single commit; all of the changes from the source branch get rolled up into one changeset pended against the target branch. So as far as I understand your question, the answer is "yes".
I'm having trouble with branching in Visual Studio TFS. This may be due to the method in which I am developing, but if this is the case, please let me know what the best practice is with branching and I will change our procedure.
About a month ago, I branched a project so that I could begin developing a new version of the web application, but didn't want the main trunk of the application to be affected by my changes as I tested and tried to get things to a production level status.
So as of a couple days ago, we became aware of a few bugs with the current version of the application that is running in production. I fixed these bugs on the main branch, redeployed the web application, and checked in the bug fixes to the main application trunk. And here is where the problem lies. Now the main trunk has the bug fixes, but my new version branch does not.
Here is my question: How do I go about doing a version compare or something of the sort to get the bug fixes into the branched project?
I may be doing things un-ordinarilly. This is due to my lack of knowledge of branching and development life cycles. Please let me know if there is a better method that you all practice in your development shops.
Cheers,
C
Sounds like you are doing the correct thing to me, you just need to merge your changes into your dev branch.
To merge the changes, you need to be in Source Control Explorer. Right click on the "source" branch (in your case that is the main branch) and then select "Merge". You will then go into the merge wizard where you can pick which branch you would like to merge into (your development branch). Personally, I always pick the "selected changesets" option on that page as it then gives you a list of changesets and you can pick the start and end of the range of changesets that you want to bring into your development branch.
Hope that helps.
Martin.
You just need to merge those changes to the new-version-branch.
A good starting point is the branching and merging guidance. Read it to find out how you can organize your branches.