What's the difference between trunk and branch in jenkins?
It sounds like you're just interested in the terms trunk and branch in general in relation to source control. Trunk generally refers to the "main" version of source for a piece of software, and a branch is a (usually temporary) diversion from this main line, usually to work on a feature which is then merged back in to the trunk.
The details depend on which version control system you are using, but here's a description in relation to SVN:
https://stackoverflow.com/a/16163/206297
Trunk would be the main body of development, originating from the start of the project until the present.
Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.
As it relates to Jenkins, you're probably interested in which version of the software the continuous integration process should be building. I'd suggest more often than not it will be the trunk, as this is the canonical version, and the one most likely to be the candidate for release. But you might have branches for legacy version, etc, which might need building too. But it will depend of course on the process for any given company/project.
Related
I've got a branch from trunk in TFS on which development is complete. I understand that merging back into trunk should be the next step, but due to a situation beyond my control, I am not able to do that. I'm satisfied the branch represents my complete application. Is there a merge option that will simply take the branch as the trunk?
As I read the MS documentation on MERGE, the baseless merge comes close to what I want. But, I understand that the trunk files would still be part of the result, which I do not want.
A branch has a name and a purpose. You could of course rename the branch, or change its purpose. You could also label your current branch... Or create a new branch from your current development branch.
Whether that's a good idea, that's something else.
I appreciate there has been some comment on this, but I am wondering whether my situation is a little different.
I am using MVC3 and VS2012. I have a solution with 2 projects, one for the web app and the other for the DB domain model.
I use TortoiseSVN as well as AnkhSVN within VS2012.
I have created a branch off the trunk where I have made quite a few changes including new DLLs and associated references. One of the big changes is upgrading Entity Framework to 6.1.1 from 5. So new dlls and namespace definitions.
The trunk has been tweaked to address some urgent mods.
I have checked out the trunk and branch into seperate local folders, and work on each seperately.
Normally, as I understand it, when one is ready to remerge the branch to trunk, one uses SVN, but this can be error prone. I am a big fan of Beyond Compare, and used it before SVN. I now use it as my diff tool within SVN. I could use Beyond Compare to copy across the modified code from the branch local folder to the trunk local folder and then "commit" the local changes back to "trunk", but this local copy across, while being robust, is very tedious.
I would be grateful if one could provide a better recommendation.
Thanks.
I have an environment where I'm building several library solutions in TFS. At the end of the build process the script packages them into a NuGet package and pushes them to our local feed.
Now we can include these libraries, which change little day-to-day, in our upstream projects.
These libraries as well as our upstream projects generally are branched at the same version. Basically the trunk is our evolving latest version. Say before branching the trunk is 3.0.0.123, 123 being a running build number. At some point we mark the current trunk as what we're going to release and branch it. The version number of the trunk at the time of the branch becomes the version of that branch and we would increment the version in whatever appropriate manner for the trunk to what we would feel is likely going to be the next release (say 3.1.0.456).
This presents a slight oddity to how we'd like to use NuGet. We would want that the branch, 3.0.0.456, use the lateset library from the branch (perhaps 3.0.0.457) and the trunk to use the latest from the trunk (3.1.0.789)
So what this basically boils down to is can we setup the versions for a solution using NuGet to be similar to the manner NuGet uses when defining dependencies within a package?
Ideally, I'd like to tell the branched upstream application to use [3.0.0.456, 3.1) and the trunk to use latest (no version). In this scenario it would pick up the branch would pick up the next branch build (3.0.0.457) and the trunk would pick up whatever the last NuGet package that was published to the feed.
The only idea that I've come up with as a possible solution is using parameters for the build template and using that to update the package.config file before the NuGet targets are run.
I appologize if this should go on SuperUser or elsewhere...
After doing some digging to have my build do some auto creation of packages for our library projects I came to the (wrong) conclusion that this was a limitation of NuGet. I parsed their source for any XSD documents to describe their XML so that I could see how their nuspec worked.
While I had their source I started looking into how I could modify the package.config file to accept their schema for limiting versions. After some digging I found an attribute that can be added to the package node in package.config: allowedVersions. This is exactly what I was looking to add!
Once I had this piece of information I was able to dig a little deeper into how it was implemented. Turns out that this functionality has been around for a while and is even documented on their docs site: http://docs.nuget.org/docs/reference/versioning
It is in the dependency versioning guide located at the bottom. I must have completely glossed over it or never read that far!
Turns out that this was a non-issue and the only problem was my ignorance. Just a reference for any Googler's out there that land on this page!
SOURCE (LOCATED AT BOTTOM OF PAGE): NuGet Versioning
I have the Development branch forked from the Main branch.
Could I merge the Development branch back to the Main so that Main branch code would be equal the Development branch?
What is the most safe and reliable solution for this?
The easiest way I've found to do this is to do a merge using Visual Studio and the Source Control Explorer.
In the Source Control Explorer, right-click on your development branch and select Branching and Merging > Merge
In the Target Branch drop-down select your trunk ("Main") as the destination. This is likely the default selection if you've branched from Main originally.
There are two options:
All changes up to a specific versions: You choose based on a revision and merge it all up to that revision in one fell swoop. If you have a lot of changes, this can save you some time, but also is riskier in terms of resolving conflicts if there have been a lot of changes in Main.
Selected changesets: You select single or groups of changesets to merge back and then repeat this process until you've merged back what you need. Less risky option, but much more time consuming. I personally prefer this approach so that I can see the changes going back into the trunk and know what to expect as changes.
TFS will instruct you if there are merge conflicts while you are merging. This occurs when you change something in the trunk after you've branched to your development. If one of the changes you've made in development conflict with the changes you've made in the trunk, you will have the chance to resolve this in Visual Studio.
If you do not have any conflicts, your development changes will move into the Trunk and simply merge with the changes you already have there.
I admit one work place they merged the Trunk to the Branches, but its not supposed to work that way.
The generally accepted method is merge the Branch back into the Trunk.
It sounds like you are working in the Trunk ("I can create some additional folder or additional files in the trunk") and wanting to merge into the Branch.
I recommend doing it the standard way: only work in Branches merging back to the Trunk, never coding directly in the Trunk.
We are using TFS Continuous Development model
Main Trunk
-> Various Development branches
-> Various Release branches
All merging back to main trunk
Now we need some major changes to our folder structure and solutions
How do you handle folder restructure in above model of TFS usage?
do i need to draw line and create new structure from latest Main trunk and lock all branches and do updates then creates branches with restructured new trunk.
Or am i underestimating TFS, would be able to handle major folder structure updates and propagate over to branches. As long as i know if we move around folders in branch or trunk it don't like it.
TFS can handle this, and does it by "renaming" each file by changing it's TFS location path.
I've been able to do this in a child branch, merging it up into the trunk, and then back into another branch.
It does get a little tricky, and you are sometimes presented with confusing dialog boxes because it can't automatically resolve renaming changes.
When I got this box, I resolved any actual content changes in files. I was then able to cancel out of manually resolving every renaming change without any problems, and everything worked perfectly.