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 use
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...
unl
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.
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
Kie
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
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
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
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 "wo
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 s
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
--~--~-~--~~
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
>
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
Max Battcher wrote:
>
> I've helped set this up a couple of times now and it is easy enough.
> Every library/dependency of Django has an easy to find Windows
> installer (or generic Python setup-tools installer, which work in
> Windows), including Postgres 8. The Django development server works
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 + m
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
On 3/16/06, Eric Walstad <[EMAIL PROTECTED]> wrote:
> > Most of our guys use Windows, so installing fedora is going to be a
> > problem for them - I may have to think about getting a LAMP
> > installation for them under Windows (or convert them to OS-X ;)
> I've not bothered setting up a Windows d
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
On Thursday 16 March 2006 13:48, tonemcd wrote:
> Hi Eric! ;)
Hi!
> 1. ...at the moment I'm using the development server...
I miss-spoke when I said the developers have a full DAMP stack (I do, but the
others don't). We mostly use the development server on our workstations.
> Most of our guy
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
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/
Hi Eric! ;)
1. Well, you certainly have an interesting setup there - it's similar
to something I was thinking we would have to do. I use OS-X and am
*very* aware of what's needed to get mod_python and postgres working on
that platform ;) - at the moment I'm using the development server, and
that
Julio,
This is really helpful - thanks very much for the information.
We're very used to having NFS mounts and the three platforms we use;
PC, Mac and Linux, can all access that very well, so we can access file
structures in the way you've outlined. As for Apache rewrites, we've
been doing those
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 a
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 databas
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 Sub
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
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 b
27 matches
Mail list logo
