[wp-hackers] Switching from SVN

[Curtis McHale]

With Git I'd create a new branch in my client project and patch then 
issue the pull request from that branch. Then you can switch back to 
mainline and work on the stable release.

You can ignore specific client files (themes, custom plugins...) with a 
new .gitignore file in the new branch.

> ------------------------------------------------------------------------
>
> 	Mike Schinkel <mailto:mikeschinkel at newclarity.net>
> December 10, 2010 5:23 AM
>
>
> On Dec 10, 2010, at 8:16 AM, scribu wrote:
>> The current release is under tags/3.0.3.
>>
>> The stable branch is in branches/3.0.
>>
>> At the moment, the 3.0 branch is identical to the 3.0.3 tag, because there
>> haven't been any commits made yet, but that's not always the case.
>
> So with SVN I still have the issue I described; assuming I don't want to break my project by installing not released code I still have to set up another install in order to generate a patch, right?
>
>> A possible git workflow:
>>
>> 0. Clone the WP repo: git clone git://some-mirror-url.com/wordpress.git
>>
>> 1. Make some changes on the stable branch
>>
>> 2. Switch to dev branch (without loosing changes): git checkout development
>>
>> 3. Test changes and make patch: git format-patch>  patch.diff
>>
>> 4. Switch back to stable branch: git checkout stable
>
> And so for the scenario I described Git doesn't allow me to make "patches" to the released code (vs. a branch) any more than SVN, right?
>
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> ------------------------------------------------------------------------
>
> 	scribu <mailto:mail at scribu.net>
> December 10, 2010 5:16 AM
>
>
> On Fri, Dec 10, 2010 at 3:01 PM, Mike Schinkel
> <mikeschinkel at newclarity.net>wrote:
>
>> On Dec 10, 2010, at 7:44 AM, Mike Little wrote:
>>> If you are working on a fix for the current release, then you need to
>> work
>>> against the current stable *branch*.
>> So does a *branch* different from the current release?  I'm as confused by
>> all this as Otto is confused by Git.
>>
>
> Yes, it does.
>
> The current release is under tags/3.0.3.
>
> The stable branch is in branches/3.0.
>
> At the moment, the 3.0 branch is identical to the 3.0.3 tag, because there
> haven't been any commits made yet, but that's not always the case.
>
>> I'm not sure what could be any simpler than the instructions here
>>> http://wordpress.org/download/svn/
>>>
>>> There are  only 4 (svn) steps.
>> It's not running SVN that is complex, it's getting the right code to run
>> SVN against that can be complex.
>>
>
> A possible git workflow:
>
> 0. Clone the WP repo: git clone git://some-mirror-url.com/wordpress.git
>
> 1. Make some changes on the stable branch
>
> 2. Switch to dev branch (without loosing changes): git checkout development
>
> 3. Test changes and make patch: git format-patch>  patch.diff
>
> 4. Switch back to stable branch: git checkout stable
>
> Because you have the entire repo stored locally, switching branches is a
> snap.
>
> Of course, there are some catches, like a possible db-upgrade, which might
> be harder to change back from.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> ------------------------------------------------------------------------
>
> 	Mike Schinkel <mailto:mikeschinkel at newclarity.net>
> December 10, 2010 5:01 AM
>
>
> On Dec 10, 2010, at 7:44 AM, Mike Little wrote:
>> If you are working on a fix for the current release, then you need to work
>> against the current stable *branch*.
>
> So does a *branch* different from the current release?  I'm as confused by all this as Otto is confused by Git.
>
>> I'm not sure what could be any simpler than the instructions here
>> http://wordpress.org/download/svn/
>>
>> There are  only 4 (svn) steps.
>
>
> It's not running SVN that is complex, it's getting the right code to run SVN against that can be complex.
>
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> ------------------------------------------------------------------------
>
> 	Mike Little <mailto:wordpress at zed1.com>
> December 10, 2010 4:44 AM
>
>
> Mike,
> If you are working on a fix for the current release, then you need to work
> against the current stable *branch*.
> In the instructions here http://wordpress.org/download/svn/ (mentioned in
> one of the answers to your question the checkout would be
>
> svn co http://core.svn.wordpress.org/branches/3.0
>
> Make sure to indicate that your patch is against the branch when you 
> submit
> it.
>
> I'm not sure what could be any simpler than the instructions here
> http://wordpress.org/download/svn/
>
> There are only 4 (svn) steps.
>
> The only ones missing are 'do an svn revert and svn up' when you want to
> start on the next piece of work.
>
>
>
> Mike
> ------------------------------------------------------------------------
>
> 	Mike Schinkel <mailto:mikeschinkel at newclarity.net>
> December 10, 2010 4:30 AM
>
>
> On Dec 10, 2010, at 6:40 AM, Peter Westwood wrote:
>> How is switching VCS going to magically make it easier.
>
> I wasn't so much arguing for a switch as I was explaining why I don't produce nearly as many patches as I would like with the hopes someone could point out how to do it easier.
>
> And/or if those who know distributed vc well say it's possible, then my scenario would be just one data point to support it.
>
>> 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.
>
> Then after all this time I still don't understand how patching is supposed to work.  My assumption has always been that I had to patch from trunk.  Maybe you could be so kind as to review this and make comment?
>
> http://wordpress.stackexchange.com/questions/990/easiest-way-to-create-a-patch-for-submission-to-wordpress-core
>
> To be clear you are saying that if a project I'm working on is the current stable release I can generate a patch from it after modifying core and that will work for you?
>
> -Mike
>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

-- 
Curtis McHale
SFNdesign
604.751.3482
http://curtismchale.ca
http://twitter.com/curtismchale
http://ca.linkedin.com/in/curtismchale