Re: How do I propose changes to Subversion repos?

[Mark Phippard]

On Thu, Dec 7, 2023 at 12:28 PM Jason Yundt  wrote:
>
> On Thu, Dec 07, 2023 at 04:12:00PM +0100, Daniel Sahlberg wrote:
> > Den tors 7 dec. 2023 kl 15:43 skrev Jason Yundt :
> >
> > > 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
> > > , 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
>
> That was really helpful. Thank you!

I would also ask the project you are contributing to how they like to
receive contributions. Maybe they have it documented. If they receive
patches via mailing list like Apache projects do, then maybe you can
see that list for examples of other contributions and what they look
like. The Subversion project had a commit message style the committers
care about so I always would review recent contributions as a reminder
... of course you can also see those by running svn log to get a sense
of what commit message style is in the project.

Mark

How do I propose changes to Subversion repos?

[Jason Yundt]

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 ).

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  && 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  &&
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  &&
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 /trunk/ -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?

• I followed my own instructions to create an example patch for
, and I attached it
to this email. Does it look like I created the patch correctly?

[1]: 
[[[
Do random stuff

* New file,
* README:
  Change for the sake of change
]]]

Index: New file
===
--- New file(nonexistent)
+++ New file(working copy)
@@ -0,0 +1 @@
+This is a new file.
Index: README
===
--- README  (revision 1914430)
+++ README  (working copy)
@@ -1,5 +1,6 @@
 
Subversion, a version control system.
+   asdfasdfasdfasdfasdfasdfasdfasdfasdf
=
 
 $LastChangedDate$

Re: How do I propose changes to Subversion repos?

[Daniel Sahlberg]

Den tors 7 dec. 2023 kl 15:43 skrev Jason Yundt :

> 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 ).
>
> 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  && 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  &&
> 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  &&
> 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 /trunk/ -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
> , 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

Re: How do I propose changes to Subversion repos?

[Jason Yundt]

On Thu, Dec 07, 2023 at 04:12:00PM +0100, Daniel Sahlberg wrote:
> Den tors 7 dec. 2023 kl 15:43 skrev Jason Yundt :
>
> > 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
> > , 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

That was really helpful. Thank you!