Can SVN pull request same as GIT?

[钱海远(Nathan)]

Dear Sir,

We want to develop a feature like git pull request .

But it is not easy to develop. Svn has only one server , how to store the patches? If build failed , how to revert working copy. How to resolve the conflict.

Git is a better , it can support pre-commit code review, pull request by default. Is subversion able to develop these features in the future?.

We like subversion ,we build a lot tools for subversion, like the pre-commit code review、issue plugin、code count、svn multisite (same as Wandisco’s svn multisite plus) ,but it’s became hard and hard, is it time for us to give up svn?

________________________________
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!

发件人: Johan Corveleyn [mailto:***@gmail.com]
发送时闎: 2018幎10月16日 20:34
收件人: 钱海远(Nathan)
抄送: Subversion; Julian Foad
䞻题: Re: a issue of --include' and '--exclude' options on 'svnadmin dump'

On Tue, Oct 16, 2018 at 11:56 AM 钱海远(Nathan) <***@hikvision.com<mailto:***@hikvision.com>> wrote:
Dear Sir,

During I am testing the -include' and '-exclude' options on 'svnadmin dump' , I found that if I copy a non-include file, the dump result is to add a file with file content; But if the copy is a non-include directory, the dump only adds this directory.

I think, this may be wrong, it should be copy of the directory and all the files under the directory .

[***@RD-230 subversion]# svnadmin dump /data1/svnroot/Dev --incremental -r 13386 --include "/CM Action/Tools" > /tmp/test.dmp

已蜬存版本 13386。
[***@RD-230 subversion]# cat /tmp/test.dmp
SVN-fs-dump-format-version: 2UUID: 313b818e-f7ce-944b-8d5d-4aca2895b6b9

Revision-number: 13386
Prop-content-length: 89
Content-length: 89

K 10
svn:author
V 11
qianhaiyuan
K 8
svn:date
V 27
2018-07-04T04:18:48.877124Z
PROPS-END

Node-path: CM Action/Tools/diffcount
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

PROPS-END

In fact, the copy directory has many files. But the dump file is only add a new dir.
[cid:***@01D46572.FAAA9F30]

________________________________

Hi Nathan,

Thanks for reporting this.
I see you had previously filed an issue about this in our issue tracker:
https://issues.apache.org/jira/browse/SVN-4760 (a issue of --include' and '--exclude' options on 'svnadmin dump')
(and added this in comment to the "feature request issue" https://issues.apache.org/jira/browse/SVN-4729 (Add '--include' and '--exclude' options to 'svnadmin dump'))

And you were directed here to discuss the issue.

This does indeed look like a bug / shortcoming of the current "dump with include/exclude".

I hope someone with expertise in this area of funtionality might be able to comment here.

[Julian Foad]

Post by 钱海远(Nathan)
We want to develop a feature like git pull request .
But it is not easy to develop. Svn has only one server , how to store the patches?
If build failed , how to revert working copy. How to resolve the conflict.
Git is a better , it can support pre-commit code review, pull request by default. Is
subversion able to develop these features in the future?.

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.

If you really want the PR not to be committed to a branch, so that you can permanently delete it if it fails, then you need to store patches somehow. That is an area where Subversion is currently very weak. I am currently working on client-side shelving. Shelving provides a way to manage patches on the client side (in a working copy), better than standard diff/patch files. This was released in a simple form in v1.10, and improved in v1.11. Once this is working well on the client side, it should be possible to extend the idea towards the server side. Read more about it in the Wiki [1] and come and talk to us on dev@ about developing that further.

You said that you build a lot of tools for Subversion. It would be good if you can come to the Subversion development mailing list "dev@" [2] -- that is where we discuss and design and debug new feature developments. There we can share and help and learn from each other, and there is where you are likely to connect with other developers who want to do the same thing. When you are ready, if you can write a more detailed description of any of your plans, or share something that you have already developed, you could send it to dev@ and I will be interested to read it and help guide my development of the shelving and future directions, and I hope also that you will find someone else likes it too and wants to help you make it better.

[1] https://cwiki.apache.org/confluence/display/SVN/Shelving+and+Checkpointing
[2] see http://subversion.apache.org/mailing-lists.html for details.

- Julian

[Nathan Hartman]

Post by Julian Foad

Post by 钱海远(Nathan)
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.

[Branko Čibej]

Post by Nathan Hartman

Post by Julian Foad

Post by 钱海远(Nathan)
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 hope we're all aware that "pull request" is not a git feature, it's a
feature of some tools built on top of git, right? Just to keep things in
perspective. One could always build such tools with Subversion. The
workflow would be slightly different, but that really shouldn't be an issue.

-- Brane

[Nico Kadel-Garcia]

Post by 钱海远(Nathan)
Dear Sir,
We want to develop a feature like git pull request .
But it is not easy to develop. Svn has only one server , how to store the
patches? If build failed , how to revert working copy. How to resolve the
conflict.
Git is a better , it can support pre-commit code review, pull request by
default. Is subversion able to develop these features in the future?.
We like subversion ,we build a lot tools for subversion, like the
pre-commit code review、issue plugin、code count、svn multisite (same as
Wandisco’s svn multisite plus) ,but it’s became hard and hard, is it time
for us to give up svn?

This seems infeasible. The working copy in which the merges would occur
does not exist in the Subversion workflow. It's a case where git-svn could
work well, as long as you avoid the boobytraps such as difficulties merging
metadata, such as "svn:keywords" or ".gitattributes" or features like
submodules.

[Julian Foad]

Post by 钱海远(Nathan)
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

[Nico Kadel-Garcia]

Post by Julian Foad

Post by 钱海远(Nathan)
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.

[Branko Čibej]

Post by Nico Kadel-Garcia

Post by Julian Foad

Post by 钱海远(Nathan)
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.

Post by Nico Kadel-Garcia
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

[Stefan Sperling]

Post by Nico Kadel-Garcia
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.

[Julian Foad]

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

[Branko Čibej]

Post by Stefan Sperling
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

[Nico Kadel-Garcia]

Post by Stefan Sperling

Post by Nico Kadel-Garcia
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.

Post by Stefan Sperling
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.

Post by Stefan Sperling
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,
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.

Post by Stefan Sperling
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
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.

[Daniel Shahaf]

Post by Nico Kadel-Garcia

Post by Stefan Sperling
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,
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.

Post by Nico Kadel-Garcia
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

[钱海远(Nathan)]

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:***@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:***@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:***@apache.org]
发送时闎: 2018幎12月2日 0:07
收件人: ***@subversion.apache.org
抄送: 钱海远(Nathan)
䞻题: Re: Can SVN pull request same as GIT?

Post by Nico Kadel-Garcia

Post by Stefan Sperling
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,
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.

Post by Nico Kadel-Garcia
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>

[钱海远(Nathan)]

Dear Julian,

Our code support 20+ more hardware platform, we need to make sure the code can work well at all the 20+ platform. In the past few years, we use post-commit and Jenkins Poll SCM . When the bad code check in, we will freeze the branch until the problem is fixed. It wastes other developer's time , it is difficult to guarantee that the code always works.

So we'd like to make a pre-commit CI system, if anyone who want to commit his code, we will build and test it first , if the CI passed the build and test , then it can merge to branches.

We have 2 plan:

Plan A ( 2015 we had make a linux svn issue plugin like this ,but it is easy ,just replace the svn program , see it at attachment):
1. Make a perl script to replace the svn program, rename svn bin to svn-org;
2. User can use svn commit command to commit his code ( in fact , the perl script will start) , the script will store the patches, and send it to our build system. Also script will start a daemon program work at user's computer to listen the build result.
3. When the build finished, daemon will tell user the result . We plan use svn mucc to commit the file ,then update the working copy.

Plan B (search it at google ):
1. Create a merge (pull) branch from the trunk and check that out.
2.Merge you development check-out branch into the "pull" branch.
3.Run test threads and do compares to verify the merge.
4.Integrate with the trunk.


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!


-----邮件原件-----
发件人: Julian Foad [mailto:***@apache.org]
发送时闎: 2018幎11月30日 21:20
收件人: Nico Kadel-Garcia; 钱海远(Nathan)
抄送: Johan Corveleyn; Subversion
䞻题: Re: Can SVN pull request same as GIT?

Post by 钱海远(Nathan)
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

________________________________
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>

[Julian Foad]

Post by 钱海远(Nathan)
[...]
So we'd like to make a pre-commit CI system, if anyone who want to
commit his code, we will build and test it first , if the CI passed the
build and test , then it can merge to branches.
Plan A ( 2015 we had make a linux svn issue plugin like this ,but it is
1. Make a perl script to replace the svn program, rename svn bin to svn-
org;
2. User can use svn commit command to commit his code ( in fact , the
perl script will start) , the script will store the patches, and send it
to our build system. Also script will start a daemon program work at
user's computer to listen the build result.
3. When the build finished, daemon will tell user the result . We plan
use svn mucc to commit the file ,then update the working copy.

I understand. Currently, Subversion supports patches that contain only a limited kinds of changes -- text modifications, property modifications. In the future I hope we can provide a patch format that supports all kinds of Subversion changes (copy, move, binary files, etc.). The "Shelving" developments are providing some of the support that will be necessary to do that.

Post by 钱海远(Nathan)
1. Create a merge (pull) branch from the trunk and check that out.
2.Merge you development check-out branch into the "pull" branch.
3.Run test threads and do compares to verify the merge.
4.Integrate with the trunk.

Yes, that is the other main option.

Thank you for explaining this more clearly.

- Julian

[钱海远(Nathan)]

Will you make any plan on SVN pull request?

More and more company change SCM system to Git.


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!

-----邮件原件-----
发件人: Julian Foad [mailto:***@apache.org]
发送时间: 2018年12月3日 16:48
收件人: 钱海远(Nathan); Nico Kadel-Garcia
抄送: Johan Corveleyn; Subversion
主题: Re: 答复: Can SVN pull request same as GIT?

Post by 钱海远(Nathan)
[...]
So we'd like to make a pre-commit CI system, if anyone who want to
commit his code, we will build and test it first , if the CI passed the
build and test , then it can merge to branches.
Plan A ( 2015 we had make a linux svn issue plugin like this ,but it is
1. Make a perl script to replace the svn program, rename svn bin to svn-
org;
2. User can use svn commit command to commit his code ( in fact , the
perl script will start) , the script will store the patches, and send it
to our build system. Also script will start a daemon program work at
user's computer to listen the build result.
3. When the build finished, daemon will tell user the result . We plan
use svn mucc to commit the file ,then update the working copy.

I understand. Currently, Subversion supports patches that contain only a limited kinds of changes -- text modifications, property modifications. In the future I hope we can provide a patch format that supports all kinds of Subversion changes (copy, move, binary files, etc.). The "Shelving" developments are providing some of the support that will be necessary to do that.

Post by 钱海远(Nathan)
1. Create a merge (pull) branch from the trunk and check that out.
2.Merge you development check-out branch into the "pull" branch.
3.Run test threads and do compares to verify the merge.
4.Integrate with the trunk.

Yes, that is the other main option.

Thank you for explaining this more clearly.

- Julian

________________________________
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

[Branko Čibej]

Post by 钱海远(Nathan)
Will you make any plan on SVN pull request?

No.

Subversion is a version control tool, not a code review tool. There are
plenty of those available, both open-source and commercial, and some of
them support Subversion for version control.


Now if someone wants to write a pre-commit hook that will send a pending
commit to code review, and will integrate nicely with *any* Subversion
client ... you're welcome to bring your proposal to ***@. But don't
expect someone else to write it for free in their spare time.

Post by 钱海远(Nathan)
More and more company change SCM system to Git.

That's their loss.

-- Brane

[Branko Čibej]

Post by Branko Čibej

Post by 钱海远(Nathan)
Will you make any plan on SVN pull request?

No.
Subversion is a version control tool, not a code review tool. There are
plenty of those available, both open-source and commercial, and some of
them support Subversion for version control.
Now if someone wants to write a pre-commit hook that will send a pending
commit to code review, and will integrate nicely with *any* Subversion
expect someone else to write it for free in their spare time.

And of course it turns out that someone has already written this, all it
takes is a quick search:

https://pravinrajput.wordpress.com/2016/11/23/svn-reviewboard-integration-pre-commit-workflow/

-- Brane