[wp-hackers] Switching from SVN
peter.westwood at ftwr.co.uk
Fri Dec 10 11:40:15 UTC 2010
On 10 Dec 2010, at 07:23, Mike Schinkel wrote:
> Thanks for the details. Still, that works for you but is a PITA for me.
> I typically am working on a project, which cannot be based on trunk when discover something I'd like to offer a patch for in core. If I am not pressed for an immediate deadline I could modify core in my current project as a proof of concept and if it works I'd like to be able make a patch for core from there (and then issue a rollback since I can't deliver code to clients that depend on a patched core.) But I can't do it this way.
> Instead I have to do the above and then go to another directory to pull down trunk. I have to recreate the data environment including what relevant plugins are currently installed needed for testing this issue in trunk (which sadly my development project's database already has.) That can take from 5 minutes or more than an hour, depending. Now I have to go find all my changes and reapply them to trunk. That can take 5 minutes, or longer than an hour, depending. After finally getting the idea implemented in the latest version of trunk only then can I make the patch. But since I don't work in trunk like you usually do, this is typically something that I can't devote the time to because its unknown to me how long it will take and my subsequent client deadline pressures.
> I could start from trunk when I try my core but I'd still have to redevelop the data environment and either way it just makes it too much effort most of the time.
> I'm not sure, but it sounds like Git/Mecurial/Bazaar/etc. would make it easier for me to provide patches of the core directly from my client projects instead of having to set up a trunk. If so it would be a huge win to enable me to contribute more patches to core.
How is switching VCS going to magically make it easier.
You still have the same base issue - you are rightly developing a site using the current stable release but want to patch against trunk.
You are still going to have to switch your code over to another checkout and test there?
In the situation you describe my process would be as follows:
1) Find bug in stable WordPress while developing client site
2) Search trac for bug reports - find nothing carry on. Find fix - apply and test out.
3) Submit trac ticket for bug
4) Create fix for bug in Stable WordPress
5) Submit patch to trac ticket against stable release.
You don't need to setup a new site or anything the checkout you have is a good place to work
In some cases your patch will apply to trunk too anyway - in other cases merging it into trunk will require some effort.
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
More information about the wp-hackers