> > I make a living visiting enterprises to help them get *to* Trunk-Based > Development and *away* from other branching models. The advocacy site: > https://trunkbaseddevelopment.com for your bookmarks :) >
> I have already read some of your site, and the impression I got was that > it's mostly about not having teams of developers working on different > branches simultaneously. And we're not planning to do that; the whole team > would only be working on one branch at a time. Our workflow would be MUCH > cleaner than the picture of the "Cascade" workflow that you show on > https://trunkbaseddevelopment.com/alternative-branching-models/ . > > I look forward to you blogging about the pros/cons in a year. In answer to your question, Subversion supports *arbitrary* branching models. The TBT way of working is just an idiom, that's perhaps supported more in the tool chain that other ways of working. Specifically, you can create a branch from http://svnServer/path/to/directory/ <http://svn.foo.com/branches/N> to http://svnServer/ somewhere/else/entirely/ <http://svn.foo.com/branches/N> and merge point tracking will make it all work over time. Try to keep merges in one direction. That's just my TBD-related opinion and the great team that maintains Svn will disagree. I may point out https://paulhammant.com/categories.html#Limits_of_Merging though. Git and Mercurial don't support arbitrary branching - all branches (and master (trunk equiv)) do the mechanics of branching from root. At least for now - over time Git changes to implement things that were previously "hell no". Subversion and Perforce support arbitrary branching. The founding dev team for Subversion around the 2001 timeframe would tell you that they were aware of Perforce and among others it was inspiration for the design/goals of Svn. - Paul
