[wp-hackers] Switching from SVN

[Ankur Oberoi]

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.

easier than that. u run one command to merge. "$ git merge scott/master
rick/master tom/master" it tracks all of the ancestry so you dont have to
look at a diff or a patch or anything. just run that and test. it's more
likely to work since it has more history to look at, and if it doesn't, you
tell them to update and send it to you again.

On Fri, Dec 10, 2010 at 12:56 AM, Otto <otto at ottodestruct.com> wrote:

> 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
> further away.
>
> > 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
> conflicting lines.
>
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>