Hi! Mike Dewhirst wrote: > a) It's not the standard. I've looked around at subversion repository > tutorials but can't seem to wrap my head around applying that to our > software.
Why not the standard? Many large companies do it the same way as you do. > b) Sometimes we need to change something on one site, but can't as the > file is under version control and may cause a clash when I try to > update it for a different fix later. This is exactly why you have version control :) Commit it and update from svn on the development workstations. Take a habit of updating 2-3 times a day from SVN. > c) If I'm working on a large job on a certain file on my development > site, I can't commit that file to roll out a quick bug fix. Here is where branches and tags come into work :) You can use one of two workflows: - use tags for "stable" versions and update production from a tag. Thus you will have a tag for each stable version and can update to any of them if you have to - work in a branch and merge it to trunk when it is stable. This is harder and you cannot update to a previous version or see its content if you have to In both cases overwrite files in production unconditionally. Apache will not see these changes until you restart it (or touch wsgi file), so you have time to fix any conflicts. But if you force overwrite, you should not have any conflicts. -- Dmitry Dulepov Twitter: http://twitter.com/dmitryd/ Web: http://dmitry-dulepov.com/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
