Re: Advice on developing with django for a team of 10+
Ah, that explains things, thanks for that Fredrik. I guess I'm showing my Zope roots - not too much is done on the command line with Zope ;) 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
tonemcd wrote: > Oooh, now that's neat. My own tinkering with svn to ignore .pyc files > hasn't worked out so well... > > % svn proplist > Properties on '.': > svn:ignore "svn proplist -v" prints the property value as well. > % svn st > M magic/site1/modeltest/models.pyc > > hmmm... unless you removed some whitespace from that output, the fact that the "M" appears in the first column means that the file is already checked into subversion. svn:ignore doesn't affect stuff that you've already checked in. to get rid of the PYC files, you have to use "svn delete". --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thu, Mar 23, 2006 at 09:23:30AM -0800, tonemcd wrote: > Oooh, now that's neat. My own tinkering with svn to ignore .pyc files > hasn't worked out so well... The way I did it was to edit my ~/.subversion/config file. There is a section, "[miscellany]" that includes a "global-ignores" option. Just add "*.pyc" to this space separated list. Unfortunately this is a per-user solution, but you could add this to the user skeleton or just tell everyone to adjust this setting. Nate --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
tonemcd wrote: > I don't want my .pyc files being put into the repository, and I thought > a recursive svn property ignore would do the trick. I used the info > from http://www.nedbatchelder.com/text/quicksvn.html, specifically; See http://code.djangoproject.com/ticket/1378 for one solution Kieran --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
I'm still finding my feet with svn Eric ;) I don't want my .pyc files being put into the repository, and I thought a recursive svn property ignore would do the trick. I used the info from http://www.nedbatchelder.com/text/quicksvn.html, specifically; $ svn propset -R svn:ignore . -F ignore.txt where ignore.txt consists of *.pyc I must have done something wrong though ;) Your svnstatus looks quite handy, so I'll use something like that. 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thursday 23 March 2006 09:23, tonemcd wrote: > Oooh, now that's neat. My own tinkering with svn to ignore .pyc files > hasn't worked out so well... > > % svn proplist > Properties on '.': > svn:ignore > % svn st > M magic/site1/modeltest/models.pyc > > hmmm... > I just make sure I don't add the pyc files to the repository (or is that what you are trying to automate?). It's not so hard doing it manually as adding files happens infrequently compared to committing changes to existing files. I'm assuming you don't want to see tons of lines of '? /path/to/some.pyc' when doing and 'svn status'. My 'svn status' alias filters out files with the pyc extension so that I don't have to look those lines: alias svnstatus='svn status | grep -v .pyc | grep -v .sql' That way pyc files aren't in the repository and I don't have status output cluttered with lines I don't care about. Hope that helps, Eric. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Oooh, now that's neat. My own tinkering with svn to ignore .pyc files hasn't worked out so well... % svn proplist Properties on '.': svn:ignore % svn st M magic/site1/modeltest/models.pyc hmmm... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
I just finished up a very crude Ant "wrapper" script so that I could drive builds and tests (mostly tests, as ther isn't much to compile) from CruiseControl. It's a pretty simple setup, but I recommend it for really any sized team. I snagged the 2.4.1 release of Cruisecontrol, which pretty much "works right out of the box". For the curious and benefit of others:I'm not satisfied with the PYTHONPATH and DJANGO_PROJECT_SETTINGS environment variable setups, but it's functioning and running all the tests as we build them and add to our codebase. ---build.xml--- which uses two scripts: baselineBuild.bash and envBuild.bashbaselineBuild.bash--#!/bin/bashPROJECTPATH=/Users/heckj/Desktop/cruisecontrol-bin-2.4.1/projectsPROJECT=webcodeexport DJANGO_SETTINGS_MODULE="$PROJECT".settings export PYTHONPATH=$PROJECTPATH:$PYTHONPATH:cd $PROJECTPATH/$PROJECTrm /tmp/"$PROJECT"DBdjango-admin.py initdjango-admin.py install edmondsdjango-admin.py install admindjango-admin.py createsuperuser root my_email_address my_sekret_password python manage.py sqlindexes edmonds > index_createscat index_creates | sqlite3 /tmp/"$PROJECT"DB rm index_creates # clean up after myself...# intial data loading... python initial_data_load.py python example_data_load.py --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Also take a look at writing a few hook scripts. When ever a developer checks in code to SVN that code gets immediately deployed to a central dev server. It also generates a changelog email and sends it to the team. You can even set it up so that checkins to different branches go to different servers. An easier path is to run a cron job on a central server that does svn update every 10 min. (svn export will always pull in all the files, update will only pull in changes) But with a large group of developers you really need to get a dev process with lots of automation down now. Once you get code into production you probably won't have time to set this up. 2 more tips. pysvn makes it really easy for the hook script to talk to the repsitory, BUT if you running solaris (and using the binary subversion from sunfreeware that does not include the pysvn binding, and your sysadmin is too busy to recompile and upgrade because you didn't setup this level of automation a year ago...) then you should know that most svn commands have a -xml switch that generates xml output. -Aaron Held --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On 3/17/06, Jeremy Jones <[EMAIL PROTECTED]> wrote: > Actually, if you do ``svn export > http://path.to.svn.server/path/to/repository/`` > it'll strip out all the .svn cruft for you. I didn't know that Jeremy, tnx! -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thu, 16 Mar 2006 23:53:56 -0300 "Julio Nobrega" <[EMAIL PROTECTED]> wrote: > > Hey tone, > > Eric provided a good explanation of what's like working with svn. I > would like to comment a little on point number 3. > > Having everything on svn helps us on deployment too. Most software > management tips will tell you to compile your code daily. Because it > gives the development team a clear goal and discourages them to commit > bugged code. > > Here's what happens where I work: QA approves the 'build' (a svn > revision), and a Python script that I made checkout this code, removes > the .svn directories, Actually, if you do ``svn export http://path.to.svn.server/path/to/repository/`` it'll strip out all the .svn cruft for you. When I get ready to do a release (not at work, we have different procedures here), I stop working on the branch I'm no, ``svn copy`` to a new branch, and ``svn export`` the finished branch. I'm thinking of changing my release procedures and branching to a "release" branch and exporting from there - jmj --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Friday 17 Mar 2006 8:44 am, Eugene Lazutkin wrote: > > On Thursday 16 Mar 2006 10:52 pm, tonemcd wrote: > >> So, if anyone is doing something like this, I'm all ears! > > > > subversion+trac > > +1. Always use Trac, if you have several people on your team. In > this case you have a nice GUI for your project + Wiki + Issue > tracker + more. incidently subversion+trac is also the best way to do zope devel with a team - i shudder to think of developers crawling like ants over a production zope site ;-) -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Kenneth Gonsalves wrote: > On Thursday 16 Mar 2006 10:52 pm, tonemcd wrote: >> So, if anyone is doing something like this, I'm all ears! > > subversion+trac +1. Always use Trac, if you have several people on your team. In this case you have a nice GUI for your project + Wiki + Issue tracker + more. Thanks, Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Hey tone, Eric provided a good explanation of what's like working with svn. I would like to comment a little on point number 3. Having everything on svn helps us on deployment too. Most software management tips will tell you to compile your code daily. Because it gives the development team a clear goal and discourages them to commit bugged code. Here's what happens where I work: QA approves the 'build' (a svn revision), and a Python script that I made checkout this code, removes the .svn directories, encode it using Ioncube (it's PHP, remember :p) and uploads the file to the production server. It takes a minute from svn revision approved to real world server, and that's good. On 3/16/06, tonemcd <[EMAIL PROTECTED]> wrote: > > Hi Eric! ;) > > 3. that's a new one on us ;) (although Julios' comment on using pylint > is very interesting) > -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thursday 16 Mar 2006 10:52 pm, tonemcd wrote: > So, if anyone is doing something like this, I'm all ears! subversion+trac -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.in ಇಂಡ್ಲಿನಕ್ಸ வாழ்க! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thursday 16 March 2006 13:48, oggie rob wrote: > You also have to consider data - coordinating data changes can be > tricky within a team. You should at least have a policy on data in the > servers (i.e. do developers have to have a "filled" database or can > they work with an "empty" one), as well as a database conversion policy > for changes to a staging & production machine. Again this depends a lot > on how much testing you expect your developers to do. Good point. We have a set of test data and a script to load it, both of which are kept in our svn repository. During heavy development, I might reload all my test data many times a day. The reload script has safeguards to keep it from running on the production server. The unit tests would mostly create their own data on which to test. This system worked well for us. Eric. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Tone, One other thing to consider: the choice of how to integrate developers is important, but probably more so is deciding on a release schedule. Your choice of tools and developer cooperation will be dictated by this somewhat. For example, if you decide you will make changes "as they are fixed/changed" (not something I normally recommend, although that's what I'm doing it on one project now), then you will probably want to have everybody make changes that are reflected on a single server. This way all of your developers can find problems as well, rather than all using separate instances of servers and probably missing problems that way. If you decide to go on a short time-based release schedule, you might want some sort of staging server. This would allow people to test their changes without committing them, to see if they are suitable for that release. This work pretty well for service-based solutions. You might want to look up information on Agile development for more tips with short time-based releases. You could also go with a more traditional longer time- or features-based release schedule. In this situation, developers would probably work on their own servers exclusively and rely upon a QA team to test all changes that have been checked in to the trunk. I avoid this approach now because not only is it generally slow to develop (and not adaptive to changing customer needs), it also tends to introduce a lot of bugs. You also have to consider data - coordinating data changes can be tricky within a team. You should at least have a policy on data in the servers (i.e. do developers have to have a "filled" database or can they work with an "empty" one), as well as a database conversion policy for changes to a staging & production machine. Again this depends a lot on how much testing you expect your developers to do. Anyway, the short story is don't neglect your release schedule when deciding how to operate in a team. -rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Our developers get involved in a lot of projects Tom - so it's almost a combinatorial explosion situation! I've been using subversion to get the latest django updates and have found it pretty approachable, so that's a big plus. We've not decided on django yet ;) there's still Zope3, TurboGears and RoR to consider, but I've been very impressed with django and to be honest, the learning curve WRT Zope3 just seems *waay* too high. RoR is a different language altogether - so that's going to be a high hurdle. Thanks for your comments! 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On Thursday 16 March 2006 09:22, tonemcd wrote: [...] > 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. Hey Tone, We do something similar: 1. Each developer has a full 'DAMP' stack - Django/Apache/mod_python/PostgreSQL - installation on their workstation. Our developers work on a mix of Fedora and OSX systems. The OSX guy had the most difficulty getting the stack setup, taking about a day to get it completely setup (lots of compiling was needed). Setup is dead simple with Fedora using yum. It's great having a full local install because it allows us to work anytime, any place, checking in our work when we're net-connected. 2. We use svn as our code repository and trac as our issue tracker. The two integrate well - I'll never choose cvs or bugzilla again. 3. Unit testing is done locally before checking in code. 4. Our staging server is also running Fedora. It holds our svn repository, trac and the DAMP stack. We use it for functional testing. 5. The production server is a remote RHEL box. When it's time to move code to this machine, its as simple as ssh'ing in and doing an svn update from our svn server and restarting apache. Before this project I had never used svn nor trac. It took me less than a day to RTFM, install, setup and configure the svn repository/server and trac. After that, we were all happily using svn and enjoying the features of trac. We were a little nervous about switching to a new repository at the begining of the project, but it's turned out to help us be more productive than if we had stuck with cvs/bugzilla. I installed a GUI client for svn, but I found I like the command line interface better. All the testers seem to like trac better than bugzilla. I like that it's all in [mod_]python and therefore easy on my eyes and brain (bugzilla is in perl). I encourage you to give it a try. Good luck, Eric. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
Option number three is the most common, and what we use here at work (even though it's PHP, the principle is the same). With one difference, the source code for each individual lies on the server. Here where I work, each user has a /home/ sub-directory on a server with Apache, PHP, Mysql and Subversion. The /home/ directories are shared using Samba. I used to use Linux, and now I use Windows, but the principle is the same. My "home" on the server appears on My Network Locations, I just open files there and edit them. Apache is setup to rewrite calls to http://ser.ver.ip/home/my_name/my_project/ to filesystem's /home/my_name/my_project/. So, when I edit a file on my /home/, I don't break anyone else's copy and I can see the changes by loading "/my_" URLs. From time to time, we commit things to a SVN repository. This is *crucial*. You mentioned that you don't have much experience with version control software, so it's a good chance to learn it :) Because with SVN, all I have to do is "svn update" (or use Tortoise, it's very good!) and get the changes done by anyone else. If you have, your QA team or testers can checkout a copy to test the latest developments. With Python and Django, nothing much changes from this process. You still can have Apache rewriting to shared directories. And maybe pylint running daily on the code... On 3/16/06, tonemcd <[EMAIL PROTECTED]> wrote: > > 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. -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice on developing with django for a team of 10+
On 3/16/06, tonemcd <[EMAIL PROTECTED]> wrote: > > 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. I couldn't imagine managing 10 developers on a project without a revision control system. Subversion is easy to learn and easy to use; I'd highly recommend you go that route with your project. Good luck -- and I'm glad to see you picked Django! :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Advice on developing with django for a team of 10+
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 -~--~~~~--~~--~--~---
