On 08.03.2018 13:22, Paul Hammant wrote:
>
> 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
> <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/
> <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.
More or less. Maybe.
In other news, 'trunk' is just another branch ... and I for one would
have been happier back then if we hadn't singled it out in the
recommended repository structure. Something like 'branches/main' would
have been less confusing in the long run, IMO.
The long and short of it is that whatever branching model you decide to
use, its success depends on discipline and documentation more than
anything else (as well as fitting the tool's (mis)features, of course).
Whether or not cascading branches work for you really depends on whether
they fit your development and release management methods.
-- Brane
Received on 2018-03-08 18:03:54 CET