trunkless svn: using svn without a trunk

[Jay Foad <ja...@gmail.com>]

Does anyone have experience of using svn without a trunk?

We use svn for a product with an annual release cycle. All new development
is done on trunk. Once a year we take a release branch, for fixing bugs
reported by customers.

One slight annoyance with this model is that when we start working on
version N of the product, it lives at http://svn.foo.com/trunk, but later
(after we have made the release branch) that same version lives at a
different location, http://svn.foo.com/branches/N. This means we have to
update some buildbots and svn:externals and whatnot that pointed to the
previous location.

In order to avoid that (amittedly minor) pain, we are considering moving to
a "trunkless" model where we abandon the use of http://svn.foo.com/trunk
and always work on
http://svn.foo.com/branches/N for some value of N. When we start working on
version N+1 we will create .../branches/N+1 as a branch of .../branches/N,
and start working there.

By the time we get to version 100 we'll be working on a branch of a branch
of a branch of a branch of ... 99 times over.

Does anyone have any experience of how well this works out in practice?

(In case it makes a difference: we don't tend to use a lot of feature
branches, so don't tend to do many big merges. I don't expect that to
change, regardless of whether or not we go trunkless.)

I'm aware of one technical problem: it'll be harder for us to do bisection
on our source code, because "svn update -r X" does not let you update to a
revision X that is older than when the current branch was created. I'm
optimistic that this can be improved in a future version of svn.

I found some previous discussion here:
https://svn.haxx.se/users/archive-2007-01/0354.shtml
But I'm still wondering if there are any other technical problems I should
be aware of, or if there have been any relevant changes in the last 11
years of svn development.

Thanks,
Jay.

Re: trunkless svn: using svn without a trunk

[Paul Hammant <pa...@hammant.org>]

> 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.



All of that is true of course, but one last word from me about cascade:
https://issues.apache.org/jira/browse/SVN-3495 - was the facilitator (in an
airline doing concurrent development of consecutive releases) for a
permanent flip from cascade to canonical trunk based development (with
build+boot+runtime toggles/flags and branch by abstraction).  The airline
went multi-repo in Git some years later, and does the GitHub-flow model
(not GitFlow) but it is still the same ... *except for the loss of atomic
commits.*

- Paul

Re: trunkless svn: using svn without a trunk

[Branko Čibej <br...@apache.org>]

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

Re: trunkless svn: using svn without a trunk

[Paul Hammant <pa...@hammant.org>]

>
> 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

Re: trunkless svn: using svn without a trunk

[Jay Foad <ja...@gmail.com>]

On 8 March 2018 at 11:56, Paul Hammant <pa...@hammant.org> wrote:

>
>
>> Does anyone have any experience of how well this works out in practice?
>>
>
> 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/ .

Jay.

Re: trunkless svn: using svn without a trunk

[Paul Hammant <pa...@hammant.org>]

>
> Does anyone have any experience of how well this works out in practice?
>

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 :)