Den tors 7 dec. 2023 kl 15:43 skrev Jason Yundt <jason@jasonyundt.email>:
> Hi, > > I’m pretty familiar with Git, but Subversion is very new to me. When I > contribute to projects that use Git, the process typically looks like > this: > > 1. If I don’t already have one, then make a clone (git clone <URL>). > > 2. If I already have a clone that’s been sitting around for a while, > then switch to the main branch and pull any changes > (git switch <whatever> && git pull). > > 3. Create a new branch for my changes (git switch -c my-branch). > > 4. Make the changes that I want to contribute. > > 5. Commit the changes (git commit). > > 6. Depending on what project I’m contributing to, do one of the > following: > > • Create a fork on whatever forge the upstream project is using, > push my branch there (git remote add my-fork <URL> && > git push my-fork) and then use the forge to create a pull > request. > > • Push my branch to any remote (git remote add my-repo <URL> && > git push my-repo), generate a message using git-request-pull and > then send that message to a mailing list. > > • Use git-send-email. > > --- > > I’m trying to figure out the Subversion equivalent of that process so > that I can contribute to an open-source project that uses Subversion. > Here’s what I’ve been able to figure out by looking at the patch > submission guidelines for Subversion itself [1]: > > 1. If I don’t already have a one, then make a working copy of the > project’s trunk (svn checkout <URL>/trunk/ <project>-trunk). > > 2. If I already have a working copy that’s been sitting around for a > while, then update it (svn update). > > 3. Make the changes that I want to contribute. > > 4. Generate a patch (svn diff -x-p > my-changes.patch). > > 5. Open the patch with a text editor and write my log message at the > top. Put triple square brackets around the message. > > 6. Email the patch to the project’s mailing list. If possible, attach > the patch with a text/x-diff, text/x-patch, or text/plain MIME type. > > --- > > Here’s the questions that I still have: > > • With Git, there’s multiple different ways of sending your changes > upstream (pull requests, git-request-pull and git-send-email). Are there > multiple ways of doing it with Subversion or do you always just send > emails with patches attached? > Unfortunately there are no equivalents of Github that offer the "pull requests" functionality for Subversion as far as I know. The normal process, at least within the ASF, is to create a patch and either attach it as a file (more below) or directly within the e-mail itself. The other solution would be to commit directly to the actual repository but then you need write access (it IS possible to say "Jason has rw access to /jasons-branches/ and r access to everything else except /private where he has no access" if one would like to create a "staging area", then you could create your own branch and request merges from that one, but the process would be much less intuitive than the Github pull request process). Subversion has the ability to do merges from foreign repositories [2] so in theory it would be possible to create your own repository, commit your patches and ask the remote party to merge these commits, but it is also not very intuitive. > > • I followed my own instructions to create an example patch for > <https://svn.apache.org/repos/asf/subversion/trunk/>, and I attached it > to this email. Does it look like I created the patch correctly? > I would prefer to not have the log message in the patch file and instead add it in the e-mail. That way it would be much easier to apply the patch, otherwise you need to edit the file before applying it. The triple brackets are used in an e-mail to indicate something verbatim in a mail, such as: Suggested log message: [[[ * README: Add some nonsense as an example ]]] It could also be used to add the patch directly in the e-mail. Kind regards, Daniel > [1]: < > https://subversion.apache.org/docs/community-guide/general.html#patches> > [2]: https://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata
