[wp-hackers] Switching from SVN
otto at ottodestruct.com
Fri Dec 10 05:56:14 UTC 2010
On Thu, Dec 9, 2010 at 11:45 PM, Eric Mann <eric at eam.me> wrote:
> 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.
So in other words, there's no way for me to get *only* your changes. I
have to get your changes plus lose changes from everybody else
(including trunk) that you have yet to merge with.
How can I test two different "branches" together, at the same time?
Because right now, all I really have to do is to apply both sets of
patches to my working copy. If they don't work, I revert.
> 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.
True that, but that is mainly because different people are submitting
different ideas and not all working on one set of code. An analogous
situation would be if each person made their own "branch" and worked
on it independently. Enabling developers to work from each others
branches is good, but it doesn't magically solve the problem since
different people have different ideas and means of implementation.
Honestly, your way sounds like more work, since you just get people
arguing over what should be in a branch while trunk goes further and
> Merging a branch is no different than applying a patch. Currently, the
> "merge burden" is on the maintainers.
I don't see how, unless they take it upon themselves to refresh the
patch. Which, admittedly, does happen sometimes, but usually only for
smaller patches. The thing I like about patches is that *I can read
them directly*. I don't need to merge them to know what they'll do,
most of the time. The patch itself contains, in a minimal set of code,
pretty much the explanation of what it does and how it works. I
generally know what it'll do without merging it and without trying it.
I can spot code errors in it without testing. A diff is more than
capable of standing alone.
>> 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.
Weird. I've never seen a patch that didn't merge, or that wasn't
easily resolved. You just look at the conflict file and fix the
More information about the wp-hackers