You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2018/12/01 00:19:06 UTC
Re: Can SVN pull request same as GIT?
On Fri, Nov 30, 2018 at 8:20 AM Julian Foad <ju...@apache.org> wrote:
>
> Nico Kadel-Garcia wrote:
> > On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) <qi...@hikvision.com> wrote:
> >> We want to develop a feature like git pull request .
> >> [...]
> >
> > This seems infeasible. The working copy in which the merges would occur does not exist in the Subversion workflow.
>
> Hello Nico! What do you mean? If Nathan is developing a Subversion pull request workflow, his software can create a WC when it needs one.
>
> Hello Nathan. I am having difficulty knowing what you really require. "Like git pull request" could mean lots of different things. It would help if you can describe exactly what you require.
>
> - Julian
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.
Re: Can SVN pull request same as GIT?
Posted by Julian Foad <ju...@apache.org>.
Stefan Sperling wrote:
>Sorry Nico, I don't see your point at all. […]
>So regarding what Nathan is actually asking about: […]
I guess that Nico understands Subversion but maybe confused "pull request" with the "git pull" command.
As for the rest, until Nathan clarifies his needs, we're all speculating.
- Julian
Re: Can SVN pull request same as GIT?
Posted by Branko Čibej <br...@apache.org>.
On 01.12.2018 10:00, Stefan Sperling wrote:
> 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.
Just to be clear: my issue is not whether SVN provides the tooling, but
with this conflation of "feature" and "tool". The very phrase "git pull
request" is tremendously misleading, because "git" doesn't provide a
"pull request" feature in the first place.
One can hardly think rationally about solving a problem if the problem
isn't stated clearly in the first place.
-- Brane
答复: Can SVN pull request same as GIT?
Posted by "钱海远 (Nathan)" <qi...@hikvision.com>.
In the past, we used another way to implement functions similar to pull requests:
We make a pre-commit code review like this ( we named it as Force Review):
1.Before developer commit code, user can use ForceReview command to create an online code review. ForceReview command is a tool to upload patches and start review .
It can work at working copy, command like this : ForceReview @ReviewerA @ReviewerB -m ${Subject}
2.Reviewer review the code , and complete it. In fact , user will change his code and iterative pre-commit review.
3.When code review completed, developer can use code review ID to commit his code. One ID can only commit his code one time.
SVN use a pre-commit to make sure the code has code reviewed:
1.First we will define which code need to code review. We use regular expression to match those code.
[cid:image001.png@01D48AF9.45E3BDF0]
2.Then pre-commit script will get the code review ID in log message. And to determine if the code is allowed to be commit.
[cid:image002.png@01D48AF9.45E3BDF0]
Best Regards!
Haiyuan Qian
R & D Management Group
Hangzhou Hikvision Digital Technology Co.,Ltd
No.555 Qianmo Road, Binjiang District, Hangzhou 310052, China
T (86571)88075998－20081
M (86)18969199712
本邮件及其附件含有海康威视公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HIKVISION, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
-----邮件原件-----
发件人: Daniel Shahaf [mailto:danielsh@apache.org]
发送时间: 2018年12月2日 0:07
收件人: users@subversion.apache.org
抄送: 钱海远(Nathan)
主题: Re: Can SVN pull request same as GIT?
Nico Kadel-Garcia wrote on Sat, 01 Dec 2018 09:25 -0500:
> On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <st...@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
________________________________
CONFIDENTIALITY NOTICE:
This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system. For further information about Hikvision company. please see our website at www.hikvision.com<http://www.hikvision.com>
Re: Can SVN pull request same as GIT?
Posted by Daniel Shahaf <da...@apache.org>.
Nico Kadel-Garcia wrote on Sat, 01 Dec 2018 09:25 -0500:
> On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <st...@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
Re: Can SVN pull request same as GIT?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling <st...@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.
Re: Can SVN pull request same as GIT?
Posted by Stefan Sperling <st...@elego.de>.
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:
http://svn.apache.org/viewvc/subversion/branches/1.11.x/STATUS
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.
Re: Can SVN pull request same as GIT?
Posted by Branko Čibej <br...@apache.org>.
On 01.12.2018 01:19, Nico Kadel-Garcia wrote:
> On Fri, Nov 30, 2018 at 8:20 AM Julian Foad <ju...@apache.org> wrote:
>> Nico Kadel-Garcia wrote:
>>> On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) <qi...@hikvision.com> wrote:
>>>> We want to develop a feature like git pull request .
>>>> [...]
>>> This seems infeasible. The working copy in which the merges would occur does not exist in the Subversion workflow.
>> Hello Nico! What do you mean? If Nathan is developing a Subversion pull request workflow, his software can create a WC when it needs one.
>>
>> Hello Nathan. I am having difficulty knowing what you really require. "Like git pull request" could mean lots of different things. It would help if you can describe exactly what you require.
>>
>> - Julian
> git pull requests perform a merge in the local repository.
There are no "git pull requests". There are GitHub pull requests, and
BitBucket pull requests, and Gerrit pull requests, and so on. It doesn't
really matter whether or not they're all implemented the same way.
> 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.
Nonsense. You're describing one _posslble_ way to implement a "code
review with automatic merge" workflow. What people tend to call "pull
requests" these days is a feature that's quite a bit older than git (or
bitkeeper before that) and worked just fine with centralised
repositories. Let's not confuse the forest and the trees.
-- Brane