On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <s...@elego.de> wrote: > > 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.
I should have been more clear about a "git pull request", which usually includes an attempt to request a merge in someone else's upstream repository. For that to to work as a request, they need to *your* distinct repository to perform the merge *from*, and that means exposing the merge source repository to the merge target repository. That.... gets pretty hairy and would take a complete restructuring to support. By working copy and repository, I meant to use Subversion language. History lives in, and can be updated in, a repository. Since Subversion supports only a working copy for a user to submit changes to a central repository, it is not a distributed source control system. If I have a local, working copy in which I a merging chnages from varoius 3rd party repositories, and not necessarily publishing them back to any of my source repositories, I am maintaining my own repository, and trying to re-invent distributed source control systems on top of Subversion. > 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'. That is not what I heard. I heard trying to pull in the changes from one repo, push them to the other, and back. That means not just diffs, but preserving history for the changes. In theory, one could do things to do that with history, but it would pretty much have to be done commit-by-commit to preserve log history, and the individual changes would have to be *committed* upstream one at a time to bring over the history of any set of chnages from some arbitrary repository. That.... seems like a lot of work, and the local working copy (in Subversion terms) would have to know about and maintain knowledge of two upstream repositories and their histories to avoid replicating commits and applying changes twice, changes that would have to be examined for duplication. If you're willing to generate diffs and submit diff patch request to bring in changes from a second upstream Subversion repository over to a first upstream repository, OK, that's workable. But that can be done from two working copies, and doesn't require a single working copy in userland that knows in detail about both upstream repositories. > 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. 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. > 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: > http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svnconflict/ > > 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. Resolving conflicts.... is often unsafe to handle automatically. It's an important part of any merging process. I'd particularly dread dealing with "svn update" from the two distinct upstream repositories in the same local merging structure. I'm thinking about the amount of pain to resolve the two distinct repository change histories, and doing that would scare the bejeezus out of me. It really looks to me like trying to re-invent the wheel of a distributed source control system. If you need to cross-llink between Subversion upstream repositories, I'd seriously consider using git-svn to mediate the link, not because it's the theoretically purest concept, but because it's well tested and stable. There are things it won't do completely automatically, like svn:eol or svn:keywords, but I suggest that it is enough for daty-to-day work, and the programming time could be better spent elsewhere.