[BitPim-devel] First draft of cvs 2 svn conversion

[Roger Binns]

Put the shell script in a directory by itself. You'll need
to have rcs and subversion installed. At the end of the
run, it runs svnserve on port 1234. I suggest using
TortoiseSVN repo browser from a windows box pointed at

svn://linuxbox:1234/

When we do the changeover, the CVS repository will still be
maintained by SourceForge so there isn't that much point
in also bringing all the tags etc over, or a lot of other
historical baggage (eg the modified version of paramiko that
was used for a while).

I still need to remove more gunk, particularly items that
got moved from one place to another (eg webhelp). That
involves going through the Attics and seeing what isn't
used any more.

Something also worth considering is moving all the phone
code (com_*, p_*) to a subdirectory. This migration may
be the best time to pretend that things were always done
that way :-)

Roger

[Joe Pham]

Something also worth considering is moving all the phone code
(com_*, p_*) to a subdirectory.

How about something like:

/phones
/lg
vx4400,vx8100, ..
/samsung
...
/sanyo
...

or just:

/phones
*


-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Roger Binns]

Either a hierarchy or a flat space will work. The
flat space requires modifying one line. The hierarchy
requires changing all files that import another to use
a full pathname to the referenced modules.

Roger

[Simon C]

Either a hierarchy or a flat space will work. The flat space
requires modifying one line. The hierarchy requires changing
all files that import another to use a full pathname to the
referenced modules.

Full pathnames could be ugly given that we all have different development
environments, if it could work with relative it would be OK.


Simon

[Roger Binns]

Post by Simon C
Full pathnames could be ugly given that we all have different development
environments, if it could work with relative it would be OK.

They would be full relative to the top of the project. For example if
the layout looked like this:

phones
lg
phone1.py
samsung
phone2.py

If phone2 wants to reference phone1 then it would have to:

import phones.lg.phone1 as phone1

(Today it just does 'import phone1')

I was thinking we could actually do a bigger reorganization
of the files:

src (move all source code into this)
dev-doc
examples
experiments
help
helpers
tests

We also currently have unixpkg and winpkg directories. I want to move
all the build/release stuff into a seperate part of the tree like what
happened with the helpblocks to web conversion, and make it more generic.
It will reappear back here as an external named something like
buildrelease.

Roger

[Joe Pham]

Post by Roger Binns
Either a hierarchy or a flat space will work.

I went with the flat space setup. I tested out with a few phones I have and they seemd to work OK. If you all have a chance, please do a quick test to make sure your phones still work as before.

Post by Roger Binns
I was thinking we could actually do a bigger reorganization of the
src (move all source code into this)
dev-doc
examples
experiments
help
helpers
tests

I think 'help' should go under 'src', and 'resources' back to the main level.

-Joe Pham




_____________________________________________________________________
Call Anyone, Anytime, Anywhere in the World - FREE!
Free Internet calling from NetZero Voice
Visit http://www.netzerovoice.com today!

[Roger Binns]

Post by Joe Pham
I think 'help' should go under 'src',

In theory the help may be translated in the future etc.
It is rarely under the source for most other open source
projects as far as I remember but I'll go around having
a look.

Post by Joe Pham
'resources' back to the main level.

That has various issues based on how the code finds
the directory. The easiest is to have it in the
same directory as the code.

Roger