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
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...
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
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
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
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
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
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
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 +
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
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
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
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
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
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
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
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
22 matches
Mail list logo
