python under subversion (svn)

[Harry George]

I'm experimenting with svn. What is the best way to set up the
original project, anticipating "importing" to a truck-and-branch
world?

When I start I have:
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

To do branches, I think I'm supposed to get to end up with:

myproject/
trunk/
doc/
mypackage/
stable.py
test/
go_test
branches/
branch1/
mypackage/
changing.py
test/
go_test

But a simple "import" of the starting project doesn't get me to the
endpoint, and the "go_test" scripts have to be tweaked to point to the
right PYTHONPATH's to pickup both stable and changing modules.

Am I correctly understanding the problem? Are there clean solutions?
Should I be totally replicating the whole project under trunk and each
branch, instead of trying to keep some items on the trunk?

--
ha************@boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: [phone]

[Richie Hindle]

[Harry]

I'm experimenting with svn. [...]
Should I be totally replicating the whole project under trunk and each
branch, instead of trying to keep some items on the trunk?

Yes, I believe so. The way to get to where you want to go is to import your
project onto the trunk, then create a branch by taking a copy of the entire
trunk project (which sounds expensive but isn't).

You also need to decide whether your trunk and branches will live at the top
level with the projects underneath them, or whether the projects will live
at the top level with the trunks and branches underneath them. Because of
the way I'm traditionally accustomed to using CVS, I prefer to think of the
trunk and branches as top-level concepts with the projects living within
them. Hence I'd do something like this:

After import:

trunk/
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

After creating a branch:

trunk/
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

branches/
mybranch/
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

--
Richie Hindle
ri****@entrian.com

[Graham Dumpleton]

Richie Hindle <ri****@entrian.com> wrote in message news:<ma*************************************@pyth on.org>...

You also need to decide whether your trunk and branches will live at the top
level with the projects underneath them, or whether the projects will live
at the top level with the trunks and branches underneath them. Because of
the way I'm traditionally accustomed to using CVS, I prefer to think of the
trunk and branches as top-level concepts with the projects living within
them. Hence I'd do something like this:

After import:

trunk/
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

Having "trunk" at the top level and projects under it is also better when you
have multiple projects. This is because you can do one checkout of the
"trunk" root directory and get the main version of all projects in one go.
If you have the "trunk" under the project name, you have to do a checkout
on each projects trunk to get the latest of everything, which is more work.

[Harry George]

gr*****@dscpl.com.au (Graham Dumpleton) writes:

Richie Hindle <ri****@entrian.com> wrote in message news:<ma*************************************@pyth on.org>...

You also need to decide whether your trunk and branches will live at the top
level with the projects underneath them, or whether the projects will live
at the top level with the trunks and branches underneath them. Because of
the way I'm traditionally accustomed to using CVS, I prefer to think of the
trunk and branches as top-level concepts with the projects living within
them. Hence I'd do something like this:

After import:

trunk/
myproject/
doc/
mypackage/
stable.py
changing.py
test/
go_test

Having "trunk" at the top level and projects under it is also better when you
have multiple projects. This is because you can do one checkout of the
"trunk" root directory and get the main version of all projects in one go.
If you have the "trunk" under the project name, you have to do a checkout
on each projects trunk to get the latest of everything, which is more work.

I know the svn recommendation is trunk at the top. But we have
several substantially separate development efforts in the same
repository, so we don't wnat to check out everything. The development
groups don't even know each other. I'm thinking I need a separate
repository (with trunk at the top) for each community.

--
ha************@boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: [phone]