Patch vs checkin
Ben Ford
I've now got the multiple-db-support branch fully merged up to date with trunk (as of rev 5559). As I've mentioned before it's in a mirrored repo, so I could commit all of the changesets incrementally back into the django svn repo (I've done 4 separate merges so far). I think that this approach has more value than one patch, as if I've screwed something up it might make it easier to catch without impacting on the other changes. On the other hand I understand the concerns raised earlier with letting anyone commit to django and I can supply a patch to one of the core devs instead if that is preferred :-).
There have been a few people who seem to be interested in moving forward with multi-db and i'd be really keen to get this stuff into svn one way or the other so others can get 'eyes on'.
The tests are currently still a bit borked... They are basically locking up the django_session table in my test database (running postgres) around about the place where the output says "Request a page that modifies the session ... ok" i'm not sure what's going on and I don't think I know enough about it to find out in a reasonable space of time.
Thanks
Ben
--
Regards,
Ben Ford
ben.f...@gmail.com
+628111880346
koenb
k
Ben Ford
None as yet, I'm really keen to get it back into the svn repo, but I think the people concerned are busy with other things at the moment. I can send you the patch if you like and I'll chase them up again.
Ben
Is there any news on updating the svn repo for this branch ?
k
Jacob Kaplan-Moss
> None as yet, I'm really keen to get it back into the svn repo, but I think
> the people concerned are busy with other things at the moment.
I've said this a couple times, but I guess it's been missed:
We're moving away from giving branch access since it's not really
worked so well in the past. It simply doesn't scale very well --
there's only one of me, and I'm quite bad about remembering to get
people access -- and people assume that SVN branches are on track to
be merged, which may not be the case.
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.
Probably the best way to host an "unofficial" branch would be by using
Tom's Mercurial mirror of Django trunk:
http://hg.korpios.com/django.trunk/.
Jacob
Forest Bond
> Probably the best way to host an "unofficial" branch would be by using
> Tom's Mercurial mirror of Django trunk:
> http://hg.korpios.com/django.trunk/.
Since you're on svn, you might also try svk.
-Forest
Deryck Hodge
> 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.
Also, it might be worth the project's time to pick a distributed VCS
and host mirrors on djangoproject.com. It would allow core devs to
pull patches in easier, I imagine. I certainly understand if you
don't want that overhead, but we're doing something similar for Samba
and it hasn't been too painful at all.
Cheers,
deryck
--
Deryck Hodge
Lead Developer, Product Development
Washington Post.Newsweek Interactive
Samba Team
Ben Ford
I'm already happily using SVK, and was originally planning to use it to remotely host the multi-db branch on my virtual server... However the only info I could find on achieving this was incorrect and I'm not sure if it is even possible to split repos (onto 2 different machine), which is what I'd originally planned...
I currently have all of the changes I've made to the branch hosted in an SVK repo, but I have no way to share those changes with interested parties - except by way of patches, which seems inelegant!
Do you know of anyway to achieve this using SVK..?
Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGlOZHRO4fQQdv5AwRAspiAJ9D3/FKYTeCw42vQok6M5u6EXnpEQCeMKbL
6n8oBKPFqBWhjKQxYQt09cI=
=pqb0
-----END PGP SIGNATURE-----
Forest Bond
> I'm already happily using SVK, and was originally planning to use it to
> remotely host the multi-db branch on my virtual server... However the only info
> I could find on achieving this was incorrect and I'm not sure if it is even
> possible to split repos (onto 2 different machine), which is what I'd
> originally planned...
> I currently have all of the changes I've made to the branch hosted in an SVK
> repo, but I have no way to share those changes with interested parties - except
> by way of patches, which seems inelegant!
> Do you know of anyway to achieve this using SVK..?
Well, I've actually only used svk very briefly to check it out, but I seem to
remember that the model is something like this:
* Mirror remote svn repository locally.
* Make a branch of the mirror.
* Make a checkout of the branch.
* Make changes to the checkout.
* Commit to the local branch.
* Merge the local branch into the local mirror; this effectively pushes the
changes to the remote svn repository.
See here:
http://svk.bestpractical.com/view/UsingSVKAsARepositoryMirroringSystem
It's on of those svn-ish things that sounds incredibly impossible if you haven't
done it before, but probably isn't all that bad. :)
-Forest
Jacob Kaplan-Moss
> Also, it might be worth the project's time to pick a distributed VCS
> and host mirrors on djangoproject.com.
Tom's Mercurial mirror is basically the official DVCS version of
Django; if it gets popular at all we'll probably move it onto
djangoproject.com.
Jacob
Brian Harring
>
> On 7/11/07, Jacob Kaplan-Moss <jacob.ka...@gmail.com> 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.
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
Deryck Hodge
Gotcha. Didn't follow that from the original comment. Thanks for the
clarification.
Cheers,
deryck
Deryck Hodge
Yeah, bzr-svn is nice. I have requirements that prevent me from using
it day to day. SVN version, primarily. But really, it's roughly the
same work flow, bzr-svn just consumes the svn data for you. I was
only offering an example based on my usage. Merging hasn't been hard
for me, but my use case is very specific -- syncing Django trees used
at work with a particular official SVN branch with very minimal
patches. Doing full-blown distributed development in BZR, you're
right that bzr-svn makes life easier.
koenb
On 11 jul, 16:12, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
> On 7/11/07, Ben Ford <ben.for...@gmail.com> wrote:
>
> > None as yet, I'm really keen to get it back into the svn repo, but I think
> > the people concerned are busy with other things at the moment.
>
> I've said this a couple times, but I guess it's been missed:
>
> We're moving away from giving branch access since it's not really
> worked so well in the past. It simply doesn't scale very well --
> there's only one of me, and I'm quite bad about remembering to get
> people access -- and people assume that SVN branches are on track to
> be merged, which may not be the case.
Maybe I am missing something here. I understand why you would be
reluctant to open up new branches, but I don't understand why this
would justify keeping a branch in a 7 month old status if someone has
done the (big) effort of bringing it more or less up to date. I don't
care who commits the changes to the branch, but my idea is that since
it is there and the work has been done, it might just as well go in.
To me it seems the best way to get some new interest for the branch
and to get it moving again.
I think this is especially interesting for an important one as multi-
db. This feature really is a life-saver for those of us who have to
use existing data, but still want to have all the niceties that
working with django brings us.
>
> 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.
Isn't that what the wiki is for: to give a clear idea about the status
of a branch?
>
> Probably the best way to host an "unofficial" branch would be by using
> Tom's Mercurial mirror of Django trunk:http://hg.korpios.com/django.trunk/.
>
> Jacob
Groetjes uit België,
Koen
Jacob Kaplan-Moss
> Maybe I am missing something here.
Nah -- not really; I understand (and agree with) your objections.
We're just gonna give this different method a try for a time and see
how it works out.
Jacob
Gary Wilson
> On Wed, Jul 11, 2007 at 09:38:54AM -0500, Deryck Hodge wrote:
>> 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-
What do you mean by this? Merging from others' branches? Merging to
svn repo? I've been using bazaar lately for my work on Django, but have
only really used it on my local machine.
> 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.
I also noticed that there is a Django project set up on launchpad [1]
which has an import of Django's subversion repository and seems to be
synced at least a couple times a day from what I have noticed.
Speaking of launchpad, has anyone had much experience using it? If so,
what are your thoughts? I have been dabbling a (very little) bit with
it recently, and like what I have seen so far.
Anyone can register branches for a project, which all show up on the
project's code page. Branches can be linked to design specs
(blueprints), can set dependencies on other branches, and branches can
either be owned by an individual or a team.
> 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
Gary
Brian Harring
>
> Brian Harring wrote:
> > On Wed, Jul 11, 2007 at 09:38:54AM -0500, Deryck Hodge wrote:
> >> 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-
>
> What do you mean by this? Merging from others' branches? Merging to
> svn repo? I've been using bazaar lately for my work on Django, but have
> only really used it on my local machine.
Pardon the delay, been rather busy. If you're just importing vcs
trunk in as a single rev in bzr, you're losing data along the way-
specifically, losing each rev from the branch you're merging. This
limits the merging ability (and limits weave merging a bit), and makes
things a pita if you're trying to identify why something changed.
Basically, keep the rev granularity- importing vcs head, and commiting
that as a rev creates problems long term; simplest example is that if
I try to merge your branch into mine, it can't easily tell which revs
are shared between our branches on the trunk imports. If it's the
only option you have, sure, go that route, but personally I've found
it winds up wasting my time :)
~harring