On Fri, Nov 30, 2018 at 4:56 AM Julian Foad <julianfoad_at_apache.org> wrote:
> 钱海远(Nathan) wrote:
> > We want to develop a feature like git pull request .
>
> Some other companies are also interested in developing the same.
>
> There are a few different possible directions.
>
> You could implement pull requests (PR) using Subversion's branches. The PR
> would be some kind of message that you send to your PR server, saying
> something like, "please merge branch
> $REPO_URL/branches/pull-requests/pr1234 to $REPO_URL/branches/my-branch".
> The PR server would check out the target branch in to a WC local to that
> server, attempt the merge, commit it, and delete the PR. If the merge
> fails, the PR server can "svn delete" the PR branch; there is no way to
> permanently delete the contents of that branch from history, but in many
> cases that can be OK. If there are conflicts, the PR server can send an
> error report back to the originating user.
It seems to me that the refactorings and support for shelving/checkpointing
being developed right now are putting into place a good foundation for
implementing pull request type functionality as well. I like that merges in
Subversion are always done in a working copy, not directly on the server.
This allows to apply a PR, test, make changes, etc. The workflow for a PR
as I see it is to produce something akin to a patch file which contains the
changes and other information needed to merge, e.g. the revision the PR is
based on. Furthermore I think there should be a place in this file for
"description" or log message so that users could easily identify what the
PR is. Also that could be copied into the log message for the commit. This
PR could be sent by email or through any other means such as a bug tracker
attachment. If a future non-versioned server-side storage is implemented
then that could be utilized. But bottom line I think this depends directly
on the same logic needed for checkpointing.
Received on 2018-11-30 21:40:10 CET