Hi, Hopefully, by this time next week we will have a dedicated server (Sunfire 4100) running django and support stuff. I'd then like to start developing new applications as soon as possible after that.
I've been playing around with django on my AlPB for about 6 months now and have learnt a fair bit, but I really need some pointers for how a group would develop with django. Our background is in Zope, and virtually all the development on that platform takes place using a browser, with a relatively small amount of python scripting taking place on the server. We have quite a sophisticated Zope setup, running circa. 150 services with development servers and clustering of deployment servers, so we're no babes in the woods when it comes to web development ;) With people working with browsers, it means that people do not have the source of the site on their local machines (they may have some python scripts lying around, but the bulk of the site is held on the server). This has been handy in the past, as no one person can screw up the application (well, they can, but they have to try a bit!) We use a variety of machines to develop on, I and several others use a Mac, most people use PCs and we have some people using RH linux as their desktop. This has not mattered in the past when we've been using browsers, but with something like django, things may be different - I don't know. I see the following scenarios, and would really appreciate a heads-up if I'm way off base. 1. People ssh into the box and edit the source code directly. This is going to mean a lot of hassle re: unix permissions and over-writing of other peoples work. The editors and other tools on the server are probably going to scare some of my people off as they use GUIs - browsers - to develop with at the moment. Telling them that emacs is the one true editor (tm) is not going to cut it I'm afraid ;) This does have the advantage that the server is the only place where the source code lives. 2. People use editors on their desktop machines and sftp to the box. Same problems as #1 wrt permissions, but at least they get an editor they're happy with. Source is now distributed. 3. People run their own local django installations, and commit changes to a development server for testing before those changes are sent to the deployment server. This means each individual user machine has to have access to the databases and keeps a copy of the source on their machine. It also means a lot of django trunk duplication on each machine (I guess we could do an 'svn up' where the target is our own django installation on the server - nice thought!). We have very little experience of using svn etc however. Our people would normally work on several projects, and with option #3, we would have to have all those projects on their local machines. I don't want to ramble on here, as I'd like to know if I'm missing something really obvious already! So, if anyone is doing something like this, I'm all ears! Cheers, Tone --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~----------~----~----~----~------~----~------~--~---
