Nico Kadel-Garcia wrote on Sat, 01 Dec 2018 09:25 -0500:
> On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <stsp_at_elego.de> wrote:
> > Note that we use such a workflow in SVN itself: When we backport changes
> > to stable branches and a merge conflict occurs, we prepare a branch.
> > Voting happens in a file called STATUS, and once the change is approved,
> > a bot known as 'svn-role' will merge it. See the log here for example:
> > http://svn.apache.org/viewvc/subversion/branches/1.11.x/STATUS
>
> But that is a branch, with its changes recorded in the single upstream
> repository. There is no split brain between repositories to resolve.
Yes, that's exactly the point. The easiest way to implement a "pull
request" workflow in Subversion is to use multiple branches within
a single repository.
At the data model level, pull requests are feature branches. The
differences are in the surrounding social patterns and in tooling built
around the "pull request - review - merge" workflow. Such tooling could
be implemented on top of Subversion 1.1.0 (sic), and has been.
> The identity, contents, and order of every individual change is there
> already. Resolving that with the individual changes and change history
> of another repository is.... well, that's where I'd expect life to get
> both difficult and dangerous.
Using multiple repositories and porting commits between them amounts to
implementing a DVCS (such as git-svn) on top of Subversion. However, as
several people already pointed out, there's no need to be distributed in
order to support pull requests. One only needs to be able to pass
patches around; branches achieve that.
Cheers,
Daniel
Received on 2018-12-01 17:14:19 CET