On Fri, Nov 30, 2018 at 07:19:06PM -0500, Nico Kadel-Garcia wrote:
> git pull requests perform a merge in the local repository. What you'd
> need to create for this is a local repository, not a working copy, and
> the working repository becomes part of a distributed source control
> system. Those already exist, so I'd discourage you from trying to
> re-invent that wheel and bolt it onto Subversion.
Sorry Nico, I don't see your point at all. I don't even understand
what argument you're trying to make here. Note that "repository"
and "working copy/tree" are rather fuzzy concepts as long as we're
talking about more than one version control system at a time.
It would be better to phrase an argument around a specific use case.
So regarding what Nathan is actually asking about:
Surely people can commit changes to branches and those branches can undergo
code review with some frontend which reads diffs from an SVN repository.
And surely some bot can run 'svn merge' when programmed to do so, just
like all the bots which run 'git merge' or 'git rebase'.
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:
Handling merge conflicts is the hard part; generally an automatic merge
must be aborted and a human needs to resolve the conflict.
Git has historically had an advantage because SVN could not merge through
renames unless guided through the whole process by the user, which is of
course incredibly tedious. But that problem is being addressed by SVN's new
interactive conflict resolver, and a scriptable frontend for this resolver
exists which could be used to automatically resolve some types of conflicts:
So I fully agree with Brane; SVN provides all the tooling required, and
people building code review tools just have to make clever use of it.
Received on 2018-12-01 10:01:10 CET