Re: Can SVN pull request same as GIT?
On 04.12.2018 12:12, Branko Čibej wrote: > On 04.12.2018 10:11, 钱海远(Nathan) wrote: >> 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 dev@. But don't > 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
Re: Can SVN pull request same as GIT?
On 04.12.2018 10:11, 钱海远(Nathan) wrote: > 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 dev@. But don't expect someone else to write it for free in their spare time. > More and more company change SCM system to Git. That's their loss. -- Brane
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 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?
On Sat, Dec 1, 2018 at 4:00 AM Stefan Sperling 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
Re: Can SVN pull request same as GIT?
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?
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
Re: Can SVN pull request same as GIT?
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?
On 01.12.2018 01:19, Nico Kadel-Garcia wrote: > On Fri, Nov 30, 2018 at 8:20 AM Julian Foad wrote: >> Nico Kadel-Garcia wrote: >>> On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) >>> 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
Re: Can SVN pull request same as GIT?
On 30.11.2018 21:39, Nathan Hartman wrote: > On Fri, Nov 30, 2018 at 4:56 AM Julian Foad 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 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
Re: Can SVN pull request same as GIT?
On Fri, Nov 30, 2018 at 8:20 AM Julian Foad wrote: > > Nico Kadel-Garcia wrote: > > On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) > > 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?
On Fri, Nov 30, 2018 at 4:56 AM Julian Foad 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.
Re: Can SVN pull request same as GIT?
Nico Kadel-Garcia wrote: > On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) > 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
Re: Can SVN pull request same as GIT?
On Thu, Nov 29, 2018 at 10:31 PM 钱海远(Nathan) wrote: > 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.
Re: Can SVN pull request same as GIT?
钱海远(Nathan) wrote: > 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
