[wp-hackers] Switching from SVN

[Ankur Oberoi]

>
> First, I update my working copy to trunk. This is not unusual, I run

trunk live, so I do that all the time. Right click the WP folder,

select SVN Update.


svn up -> git pull

Second, I make my changes. Usual editor on Windows: TextPad.


> Third, I test my changes. Since I have my trunk running live on a local
> install, this is easy. Don't even have to copy stuff around.


unchanged

Fourth, I make the diff. Right click the WP folder, select SVN->Create

Patch. Save the diff file somewhere (usually the same directory the wp

install is in). I tend to give it a name based on the number of the

ticket. Don't have to, but it helps to know what's what.


[svn add --force * (worse case)]  --> git commit -a
svn diff >> <ticket>.patch          --> git diff >> <ticket>.patch

Fifth, I upload the patch to the relevant ticket.


unchanged.

--------

my point is if your workflow is nearly unchanged if thats the way you want
to work. but if your willing to make these small adjustments you open the
door for others to work in some different (and i'd say likely to yield some
better results) ways.

better support for collaboration (nobody would have to think about how to
configure a repo to share amongst those they want to work with, it would be
a given by adopting the git system), better support for locally tracking
changes (so that you encourage understanding your development path and the
history of your mistakes/revisions), experimentation (low cost support to
try out some wilder things that have been a pain thus far because of the
hassle of a large merge).

* oh and you'll probably use less room on ur hard drive if all you're
interested in is trunk / master :)

On Fri, Dec 10, 2010 at 1:46 AM, Brian Layman <bulk at thecodecave.com> wrote:
>
> On 12/10/2010 1:25 AM, Otto wrote:
>>
>> In all the corporate environments I've used where a group had "commit"
>> access to a central repository, checking something out actually locked
>> it, and it stayed locked by that person until they released the lock
>> by checking in their changes.
>
> Not where I worked. Occasionally you would lock the database, but that was
because you couldn't do merges in the core db.
>
> Other than that, it was expected you would do multiple checkins through
out the day/week.  For example when moving to work with someone in their
office or in the projector room, you might check in incomplete code.   The
code on your desk was never to be more than 8 hours off from the repository
and the projects we were given could last weeks or longer, so you couldn't
practically check in only completed tested code.  Now, it was expected that
the code would compile and execute at the end of the day.
>
> As a result of this, merges happened all the time. No big deal.
Additionally, a couple people might split off a branch if the nature of
their project would affect the operation of the system too much and break
things for an extended period, until the work was done.  At that point we'd
merge the branches and almost always it was relatively painless. Usually, it
was done without any direct intervention as the branches were expected to
each keep up with the core code.  If there were conflicts, with three way
differences they were pretty easily resolved.
>
> -Brian
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers