We are using the release number for TFS branches. I have just created a new TFS branch with an upcoming release number. However, the client has since changed the release number which we would like to keep parallel TFS branch name.
The branch is new and no changes have been made to it yet.
What issues I can expect if I rename the branch?
Is it better to create new branch from main with the new release number?
A rename is a branch+delete under the covers.
You would be best creating a new branch with in tact history.
Related
I am creating an new branch from existing branch using Source Control Explorer (TFS) in Visual Studio 2012.
I can't see any history from the original branch in the new branch.
Is there any way to force copy of original branch history?
The new branch contains the history of original branch. You need to check history for a single file (not a folder), then you should see the history:
We have a TFS branch for our main product that on march 21st was branched to create a branch for maintenance of a specific version of the product.
The timeline looks like this:
changeset up to 37099 is on main branch
changeset 37100 is the branch changeset creating the maintenance branch
After this we have done development on the main branch, both for future versions and bugfixes intended for the maintenance branch, that has been merged.
Today we noticed that the dialog in Visual Studio 2015 that shows unmerged changesets contains two changesets below 37100, from december last year.
Tracking these changesets shows them as partial.
Since we're in the process of upgrading to TFS 2015 this weekend we're just going to let this be but is this a known bug? Should we do something about it? How can a branch contain partial changes of historical changesets? Has anyone experienced the same thing and know what should be done, if anything?
We use TFS for our version control system in AX 2012, and have been experimenting with branching for the purpose of better controlling what goes into testing and release environments.
Microsoft gives the example scenario here of a main branch, then two child branches Dev/Release.
How do you actually do this in AX? Merging in Visual Studio with XPO exports isn't the same as merging traditional source files.
Do you configure TFS parameters inside of AX to point to a Dev branch, then check-in code? Then at some point change the TFS parameters to the Release branch and re-check-in code?
What's the practical use of it?
We are using TFS integration with AX 2012 this classical way, with Main, Dev and Release branches.
TFS integration is setup in AX. Then merge at check-in if there was concurrent modifications is done by TFS. If needed, TFS merge popup if it Can't resolve the conflit itself. The merge between branches is dons in TFS too.
You must not change on the Fly the branch your are setup on. One major thing in AX TFS integration is to keep consistency between AX modelstore and local repository. When you will check an object out or get its latest version, it won't compare the TFS server version with the current in AX but in the local repository.
If you need to reaffect one dev environment to another branch, you'll have to set the modelstore and the repository local at the same level on the targeted branch and change the setup in AX.
The main purpose is to have in Dev branch all the on going developments and run nightbuilds to validate technically the current version. The Main branch is the one you will merge into validated developments to create release candidates to pus to tests and UATs. The Release branch is to have the exact version of your Live environment in order to make hotfixes without the ongoing evolution in Dev and Main branches.
We use an isolated branch per developer and a MAIN branch where we all merge to. And then extra branches for TEST and PROD for code promotion of changes.
MAIN branch has a build process that compiles it recurrently so we are sure the merged changes are still solid, and TEST branch has a build process that deploys to a test AOS for consultants. PROD branch is only for historic reasons, no build or AOS is related with this code.
I recently introduced TFS to a project team that had not been using version control. Our structure is pretty simple:
MAIN branch for production-ready code
DEV branch for (complete) test-ready code
Feature branches for incomplete code not ready for testing
As I said, this team is not used to using version control. Over the holidays a well-motivated team member decided he would try to work on a feature, however he did this directly in DEV and made a number of check-ins. His feature is not complete so I don't want it polluting DEV for now, but I don't want to lose the history of changesets.
The obvious way is to make a new branch off the last changeset before his feature, merge the rest to the new branch, and rollback DEV. However, I'm afraid I'll lose the history of changes and be left with just a single "merge" changeset in the new branch.
If this is the case, is there a way to simply move all the changesets after a certain changeset into a new branch and keep the history?
EDIT: Basically I want to turn this:
DEV ---(1)--(2)--(3)--(4)--(5)--(6)--
into this:
DEV ---(1)--(2)--(3)----------------
\
NEW (4)--(5)--(6)--
This is not supported in TFVC ( nor any other SVCS). If you were using Git is TFS there would be hope, but not here. Your suggested solution is your only avenue.
If I've started making changes, and then realize that I should have branched first, i assumed that if I create a branch "from version by workspace" I would get a new branch with my workspace version in the branch. But It doesn't seem to work that way so I'm now confused about the different options in branching "from version" with Team Foundation Server 2008.
Intentionally I would agree with you, but branching by workspace means that if you, lets say, last checked out Changeset 107 and the latest Changeset is 109 and you branch by workspace the TFS takes Changeset 107 as the base for the new branch. Local changes are ignored in that case.
Best wishes,
Fabian