Re: svn merge problem
On 17 maj 2006, at 12.45, Michael Radziej wrote: > Nicola Larosa (tekNico) wrote: > >>> /me makes another note to spend some serious time with BZR... >> >> Try spending some time with Mercurial, too. It's simpler, smaller and >> faster than Bazaar-NG, while also being written in Python, with a >> little C. > > Hmm. I'm using git for django. There's a tool that can synchronize svn > to git, and with git I can manage my own branches for patches I create > without bothering anybody. Works fine once you've got used to the, > admittedly, strange ways of git. I use Tailor[1] to sync the trunk from Subversion to a Mercurial[2] repo which I then use to merge my local changes. There is an experimental Mercurial-plugin[3] for Trac. I maintain the Mercurial port in DarwinPorts[4]. [1] http://www.darcs.net/DarcsWiki/Tailor [2] http://www.selenic.com/mercurial/wiki/index.cgi [3] http://projects.edgewall.com/trac/wiki/TracMercurial [4] http://www.darwinports.org/ - Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Graham Dumpleton about mod_python
On 18 aug 2006, at 15.07, Malcolm Tredinnick wrote: > > On Fri, 2006-08-18 at 05:54 -0700, olive wrote: >> Hi folks, >> >> Have you read the following from Django Comments, what do you >> think of >> it ? > > This seems to be in response to some question. What is the context, > though? What was the original question and where was this posted? Was > there a particular point you wanted to know about? The comments is from http://www.djangoproject.com/documentation/ modpython/ - Daniel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: More than two-levels of inline editing?
On 16 nov 2005, at 11.41, Bjørn Stabell wrote: Is there any work underway to implement more than two-levels of inline editing in the admin interface? I.e., Company/ Department/ Team/ Person in one interface? I see this talk about 'new-admin' so I'd thought I'd ask. What I've gathered from lurking is no, it's not possible and new- admin isn't the simple solution. There needs to be a merge of new- admin and after that elimination of core fields for this to be implemented. see: http://groups.google.com/group/django-users/browse_thread/thread/ 11c5adb4a4b1b9f/3f71cdab836adad4?tvc=2&fwc=2 Also, you say "two-levels of inline" when I think you mean "one-level of inline" because afaik. that's what the admin supports atm. hth, - Daniel
Re: A fix for all that futzing around with paths
On 18 nov 2005, at 18.03, Adrian Holovaty wrote: On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote: I guess I wasn't clear. What p4 does (and I propose django-admin does) is look for an environment variable called DJANGO_SETTINGS_NAME, and use " settings.py" if it doesn't find such an environment variable. It then looks for a file with that name in the CWD. If it doesn't find one there, it looks in parent directories, until it finds one. That's the settings file that is used. Oooh, this is a nice idea! Is anybody willing to submit a patch? http://code.djangoproject.com/ticket/904 - Daniel -- Daniel Ericsson http://monowerks.com/ | http://lounging.com/
Re: Removing the magic
On 7 dec 2005, at 06.21, Adrian Holovaty wrote:
But my rationale for changing to the magic object approach is: If we
move to class-based lookups (Person.objects.get_list() rather than
people.get_list()), the class will have been imported *anyway*, so
it's not too much of a big deal to have to use it.
The other magic-thread was too hot for me, I'll jump in here instead...
I find the use of "objects" as a way of namespace separation a bit
off-putting. Enforcing an invocation-style via stack inspection would
cut down on the line-noise. Not a terribly big deal, just how I'd try
to do it unless there'd be something that precludes it...
import inspect
class TestClass:
@classmethod
def get_list(*args):
frame = inspect.currentframe()
frame = frame.f_back
if not frame.f_locals:
# called via Class
print 'class'
else:
# called via an instance, raise InvalidInvocationError
or something...
print 'instance'
raise Exception
def main():
TestClass.get_list('test')
test = TestClass()
test.get_list('test')
if __name__ == '__main__': main()
regards,
- Daniel
Re: Removing the magic
On 7 dec 2005, at 10.53, Daniel Ericsson wrote: I find the use of "objects" as a way of namespace separation a bit off-putting. Enforcing an invocation-style via stack inspection would cut down on the line-noise. Not a terribly big deal, just how I'd try to do it unless there'd be something that precludes it... import inspect class TestClass: ... Actually this didn't do at all what I thought it did... sorry for the noise... at least I found a bug with that test. - Daniel
Re: Proposal: Django namespace simplification
On 13 jan 2006, at 03.32, Adrian Holovaty wrote: While we're at it, let's rename DjangoContext to something that reflects the fact that you pass in an HttpRequest object and it has context processors. RequestContext, SuperContext, FlexContext, AdvancedContext -- those ideas are all pretty lame. Ideas? It doesn't lend itself to succinct naming :) I'll throw DelegatedContext, ProcessingContext, IncreasedContext, AccessoryContext, AuxContext (for Auxiliary, but that'd be a pain to write), AugmentedContext, PseudoContext and ProxyContext into the mix. Lastly, HttpRequestProcessingContext which I think is very descriptive. Which is good right? :] - Daniel
