[wp-hackers] Switching from SVN

[Eric Mann]

>Basically, you're saying that I have to somehow hook my repo to yours just
to test a patch.

Not as complicated as that.  When I write a patch, I submit a pull request
to the central server.  Then, anyone can look at the central server and see
my branch (*not* trunk) and can switch from where they're at to my branch to
test my changes.  Other developers can then make further changes to what
I've done and commit them to my branch as well.  If you want an actual diff,
you just diff between my branch and the head of trunk.  In this situation,
you'd have one diff/patch for a ticket ... some tickets currently have
several and no real way to distinguish which are incremental changes and
which are replacements for other features.

I had to wait until post formats were formally committed, for example,
because I couldn't figure out which of the 6 patches actually made up the
feature.  Some changed the same code, some changed other code, some was
proof of concept and later in the Trac discussion rejected for a better
piece of code.

>So the merge load is put onto the maintainers then? I'd really rather have
the merge burden be on those submitting the patch in the first place, where
it is now.

Merging a branch is no different than applying a patch.  Currently, the
"merge burden" is on the maintainers.  We write code, produce a diff and
upload it to Trac.  You download the diff, apply the patch and commit.  With
a distributed system, we write code and submit a pull request (our local
repository notifies you that there are changes ready to go and exactly what
those changes are).  You pull our branch and merge it into trunk.

Merge = Apply patch

> How hard is it to apply a patch for you?

Truth be told, I've been working with WordPress for 3 years now and have
never successfully applied a patch to my own working copy.  It usually turns
out that the diff file on Trac is a version or 20 behind my working copy and
SVN doesn't know how to reconcile that problem.  If I wrote the patch, I can
always svn up and create a new diff ... but patching an existing diff back
to my working copy has proven all but impossible.

On Thu, Dec 9, 2010 at 9:34 PM, Otto <otto at ottodestruct.com> wrote:

> On Thu, Dec 9, 2010 at 11:21 PM, Eric Mann <eric at eam.me> wrote:
> > A Git base system would allow us to retain a similar system to the one we
> > have now - lots of developers can work on WordPress and submit changes
> but
> > only a select few can commit to the central repository.  When a developer
> > who's not a core contributor has a patch to submit, s/he pushes the
> > changeset to a public location (not to trunk, but to a branch of the
> > repository marked specifically for a ticket) and anyone else can clone
> from
> > that branch.
>
> Hmm.. Sorry, but it sounds complicated to me. Basically, you're saying
> that I have to somehow hook my repo to yours just to test a patch.
> Which means that I have to know some kind of obscure features of a
> version control system to somehow hook my copy of the repo into yours
> (or your branch), then do some kind of update to get your changes and
> test them.
>
> As opposed to the dirt simple process of applying a patch file.
>
> > It makes testing a patch as simple as right-clicking in a GUI ...
>
> Huh? I right click the diff file and select "Apply Patch". How hard is
> it to apply a patch for you?
>
> > If the patch is good and the core committers decide to make it core, they
> > merge it into trunk.
>
> So the merge load is put onto the maintainers then? I'd really rather
> have the merge burden be on those submitting the patch in the first
> place, where it is now.
>
>
> On Thu, Dec 9, 2010 at 11:23 PM, Ankur Oberoi <aoberoi at gmail.com> wrote:
> > its diff because for the individual, merging the changes that occurred in
> > trunk because fast and easy, and the right person for the job is doing it
> > (namely the person who knows where their code has impact and where it
> > doesnt).
>
> Err... You do an svn up and then correct the conflicts. When you're
> done with the merge (refreshed patch), you submit the diff. The burden
> of the merge is on the person creating the patch, where it should be.
> Maintainers shouldn't be tasked with any merging at all.
>
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>