Re: [pygame] [GSOC] svn and compile problem with pygame-svn

[Nirav Patel <olpc@xxxxxxxxxxxxxx>]

I personally found/find it useful to use a personal git repo, and use
git-svn to stay up to date with the Pygame SVN.  You can use "git svn
rebase" to keep your repo up to date with upstream and then commit
with "git svn dcommit" when you have code that others can
use/test/hack.

There is a decent guide for using git-svn with github here:
http://www.fnokd.com/2008/08/20/mirroring-svn-repository-to-github/

That is also useful so you have a repo to work in until 1.9 is
released and you can start committing to Pygame SVN.

Nirav

On Sun, May 3, 2009 at 1:10 AM, René Dudfield <renesd@xxxxxxxxx> wrote:
> Hi,
>
> more below...
>
> On Sun, May 3, 2009 at 2:50 PM, el lauwer <el.lauwer@xxxxxxxxx> wrote:
>>
>> Oi,
>>
>> I am installing the latest version of pygame on svn,
>> so I can start coding on my camera module. I am
>> installing it under virtualenv so I can keep using
>> the stable pygame release for my current games.
>>
>> 1)
>> I recently reseaved a svn account for the pygame
>> svn repository. How do you sugest I use this account
>> during the development prossess, should I use it to
>> commit all my changes to the main brange, or should
>> I make a personal brange just for my work on the
>> camera module. Can I use my github account instead,
>> if so, what must I do with the changes and bug
>> fixel to the main pygame development brange.
>
>
> You might want to work on the main trunk, or not... depending on a number of
> things.
>
> Either a separate branch or in your git hub is probably a good way to go.
> If you put things in svn, then it's easier for some of the pygame developers
> to watch your work, and maybe even make changes.  However it's up to you.
>
> Best to merge your work in occasionally into a svn branch at least.   Or
> send the mailing list a link to your work when you've committed something
> you'd like people to look at or merge in.
>
> Then when your work is getting along, talk about merging it into the trunk
> with the mailing list and other developers.  If no one has changed any of
> the files you have changed, then it's probably ok.
>
> Working in the trunk lets you take advantage of some other things... like
> the build bots which build on mac/win python2.4 python2.5 python2.6 and run
> the tests for you.  So it can save you a lot of testing work.
>
> Say you wanted to make some changes to surface.c and a bunch of others that
> aren't part of the camera module directly, and didn't commit to trunk for a
> few weeks... there's a good chance someone else might make changes to those
> files.
>
> As long as you communicate with other devs what your working on it should be
> fine.
>