On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <stsp_at_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.
Received on 2018-12-01 15:26:17 CET