>
> 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
Received on 2018-03-08 13:22:11 CET