On Wed, Jul 11, 2007 at 09:38:54AM -0500, Deryck Hodge wrote: > > On 7/11/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > The best thing to do is host your changes remotely. That way there's > > no implicit assumptions about if and when it'll get merged into > > Django. > > > > Hi, Jacob. > > I'll mention Bazaar, too. My experience with it has been very pleasant. > > I get a copy of Django from the official SVN, create a bzr repo off > that SVN version as is (.svn files and all). I then use bzr to track > my changes, which still allows me to SVN up. Merging is basically > just an svn up away unless I touch a file that has also been updated, > in which case I can use bzr to see what came from me instead of via > SVN. > > The UI for bzr is nearly identical to svn, so svn users should be able > to use it with little learning curve. > > For example: > > mkdir repos > cd repos > bzr init > svn co http://code.djangoproject.com/svn/django/trunk/ django_trunk > bzr add django_trunk > bzr commit > > Then you can bzr branch from there to have as many branches as needed. Doing that makes merging a fairly major PITA: alternative-
bzr branch http://pkgcore.org/~ferringb/django/trunk using bzr-svn to proxy svn directly into bzr; usually is up to date within a day or so, although if folks beyond me use it I can cronjob it to be a bit more regular. Only real downside I see to this route is that trac doesn't understand how to render bundles; so you wind up having to do bzr diff instead of just bundling the revs you want to throw at upstream. ~harring
pgpWPMOlgSCBX.pgp
Description: PGP signature
