cloning projects

[iain duncan]

I want to write a bash script to clone a project so that I can keep a
dev version of each clients project on my server and then very quickly
replace the current one when I need to. Seems to me I can either:

- use tg-admin quickstart with the new name and then copy over all
relevant files
- copy all files and rename them and references to the package name with
grep/perl
- use the exact same name isolated in a different directory ( sounds
dangerous to me ... )

Wondering what others have found to be the best solution for that before
I start bashing. If I can come up with something half way good I'll
stick it on the wiki for improvements.

Thanks
Iain

[Karl Guertin]

I vote for multiple workingenv.py instances.

[iain duncan]

On Wed, 2006-06-12 at 00:48 -0500, Karl Guertin wrote:
> I vote for multiple workingenv.py instances.

Ok, I'll put that on the "to research" list. In the meantime ( ie
tonight! ) if I am deploying two cloned projects is it standard practice
to just give each one their own port number? Is that the right way to
keep gears apps separate?

Thanks
Iain

[iain duncan]

Hmm, currently I am trying to get two copies of the same project serving
on different ports, but I'm not sure what role the project name plays. I
tried putting the same package with some diffs into two different
directories and getting apache to route them to different port numbers.
But it doesn't seem to be working. Am I perhaps doomed on this plan?

Thanks
Iain

[Lee McFadden]

What you're doing should be perfectly possibly. The project name
doesn't really play a part if you're not trying to install the project
twice from an egg.

When you say "But it doesn't seem to be working", do you have any more
info? My crystal ball is a little foggy. ;)

Lee

--
Lee McFadden

blog: http://www.splee.co.uk
work: http://fireflisystems.com
skype: fireflisystems

[iain duncan]

On Wed, 2006-06-12 at 09:32 +0000, Lee McFadden wrote:
> On 12/6/06, iain duncan <iaind...@telus.net> wrote:
> >
> > Hmm, currently I am trying to get two copies of the same project serving
> > on different ports, but I'm not sure what role the project name plays. I
> > tried putting the same package with some diffs into two different
> > directories and getting apache to route them to different port numbers.
> > But it doesn't seem to be working. Am I perhaps doomed on this plan?
> >
>
> What you're doing should be perfectly possibly. The project name
> doesn't really play a part if you're not trying to install the project
> twice from an egg.
>
> When you say "But it doesn't seem to be working", do you have any more
> info? My crystal ball is a little foggy. ;)

S'ok, got it going. i think I was having issues between browser cache,
apache restarts, and tg restarts.

Thanks for the info!

Sure am looking forward to python deployment getting easier!

Iain

[Lee McFadden]

I know I'm biased since I use TG every day, but I have no problems
deploying my apps. If there are problems with the docs on deployment
or issues which they just don't cover, a few comments on those pages
and/or some commentary here would be very helpful for future users.

[Ed Singleton]

I wouldn't say it's the best solution, but I've just been copying the
project folder and appending "_dev" or "_backup" to the folder name.
Change the port number in the config file (or even use prod.cfg for
one and dev.cfg for the other), and just run it. In itself it doesn't
cause any problems.

Some problems that can arise are:

- messing around on the command line and forgetting which directory you're in :(
- copying an sqlite database while something is writing to it can corrupt it.
- Having both sites connecting to the same database can cause problems
when you test a form or such, and enter junk test data which then
shows up on the live site.
- Forgetting to change the port number, in which case the second site
will complain that the port isn't free.

So basically, the main danger is your (my!) own stupidity. Other than
that it should work fine.

Ed

[iain duncan]

On Wed, 2006-06-12 at 09:53 +0000, Lee McFadden wrote:
> On 12/6/06, iain duncan <iaind...@telus.net> wrote:
> >
> > S'ok, got it going. i think I was having issues between browser cache,
> > apache restarts, and tg restarts.
> >
> > Thanks for the info!
> >
> > Sure am looking forward to python deployment getting easier!
> >
>
> I know I'm biased since I use TG every day, but I have no problems
> deploying my apps. If there are problems with the docs on deployment
> or issues which they just don't cover, a few comments on those pages
> and/or some commentary here would be very helpful for future users.

Mmm, I personally had a lot of problems. But I think it's kind of a dumb
luck thing too because right now dependencies are sensitive. ( ie mysl
versions, python version, distro specific apache defaults, etc ) And
yet, I had such an easy time getting rolling on my home dev box.

Anyway, I do plan on writing a tutorial covering getting going on
ubuntu. It'll be good to get comments on that when it's done!

Iain

[potens]

Seems Subversion really overkill to you ?

I mean, it the easiest way I know to have a dev version along with a
released version.
an example of repositoru could be :
projects => clients 1 => trunk (the good version)
=> branche (the dev version)
you set the svn props to avoid commiting the .pyc
when you want one or the other, you just make an export of the svn
repos (the dev one or the other).

I think you should really consider about something this way.

Hope this help (and I was not answering something stupid)

Nicolas

[Jorge Vargas]

On 12/6/06, iain duncan <iaind...@telus.net> wrote:
>

> I want to write a bash script to clone a project so that I can keep a
> dev version of each clients project on my server and then very quickly
> replace the current one when I need to. Seems to me I can either:
>

> Wondering what others have found to be the best solution for that before
> I start bashing. If I can come up with something half way good I'll
> stick it on the wiki for improvements.
>

it seems your serving code out of the directory and not an egg file,
the first thing to do will be this.

then move everything to svn, setuptools integration is great you can
have an egg named project_r50.egg project_r58.egg and so on, all you
need is to read a bit.

reinventing the wheel is only good went the current one is broken.

> Thanks
> Iain
>
>
>
>
> >
>

[Kevin Horn]

Here's what I do:

1) use subversion for every project (and usually Trac as well)
2) do a checkout on whatever dev machine I'm working on, and run the CherryPy webserver for testing/dev/etc.
3) write a bash/python script to deploy the project to live site, this script
    a) does an SVN export
    b) modifies any necessary config vars in config file, if necessary (I usually just use a seperate file for production, ex. prod.cfg)

Kevin H.