[BitPim-devel] Subversion

[Roger Binns]

SourceForge finally offers Subversion. It is *way* better
than CVS, especially for ease of use and branching/tagging.
I have been using it anger for almost a year personally
and professionally and find it a huge improvement.

I think we should move to Subversion ASAP. (Bucketloads of
other open source projects have). The SourceForge doc is
at the following link. (As a bonus there is also no time
delay for anonymous users. As a double bonus we'll never
have to whine at Joe for EOL issues again :-)

http://sourceforge.net/docs/E09/

If you are unfamilar with Subversion, reading the online book
is an excellent introduction:

http://svnbook.red-bean.com/

I am happy to do all the migration work. (I'll do it using
the dump method since I'll want to remove a bunch of cruft
like earlier versions of the compiled online help).

Since branching and tagging is so nice and easy, I'd suggest
the following practises:

- When things are ready for a release, copy to the corresponding
release number. Development can then continue on the main
branch without worrying about breaking the release.

- Each developer can have their own named area. That will make
it easier to test out new features or changes such as the
recent autodetection on startup or potential gui improvements.

- Various subprojects such as APSW and the helpblocks2web will
go into a seperate subprojects namespace. comscan will be removed.
They may be hooked into the main project/web using externals.

BTW all the Windows developers will love TortoiseSVN.

What I propose doing is making the imported Subversion repository
in my home environment using a shell script and cvs2svn. I'll
post that here for others to use in their local environment. You'll
want a recently nightly download of the CVS root:

wget http://cvs.sourceforge.net/cvstarballs/bitpim-cvsroot.tar.bz2

Once everyone is happy (next weekend?) we can do a cutover.

Roger

[Stephen Wood]

Post by Roger Binns
I think we should move to Subversion ASAP.

I agree!


--
Stephen Wood

One of the "Steves" of Project Steve at http://www.ncseweb.org/.

[Simon C]

I agree too, I really like the idea of checking out files it helps reduce
version conflict.

I sometimes work with users in order to add support for new phones, this
means sending them special test versions (I edit the test version in
version.py), do you think that this new source control will allow me to
baseline these test versions, I have lost code on occasion, so this would be
useful.

Is there a way for me to use sourceforge to host test versions of bitpim?

Simon

-----Original Message-----
Of Stephen Wood
Sent: Sunday, February 26, 2006 5:49 AM
Subject: Re: [BitPim-devel] Subversion
I think we should move to Subversion ASAP.
I agree!
--
Stephen Wood
One of the "Steves" of Project Steve at http://www.ncseweb.org/ .

[Roger Binns]

Post by Simon C
I agree too, I really like the idea of checking out files it helps reduce
version conflict.

You don't check out(*) files in any way different than CVS. What Subversion
does do differently is that it presents namespaces in a similar fashion to
a filesystem. Our tree would look something like:

/trunk /bitpim
/bpweb
/releases /0.8.07
/0.8.08
/0.8.09

Say you wanted to develop some new feature, foo. We'd have a new top
level structure /branches/simonc

You would do this:

svn copy ..../trunk/bitpim ..../branches/simonc/foo

You would checkout /branches/simonc/foo and do whatever work you wanted
there. Then use svn merge to bring the changes back to the trunk.

(*) By check out people sometimes mean that files are locked for editting.
CVS and SVN function in the same way - the difference is that SVN shows
the branches as a hierarchical name space whereas CVS uses named tokens
without altering the file hierarchy.

I think you meant what I described, and now it is explicitly laid out
for future reference.

BTW you could always have done this with CVS branches.

Post by Simon C
I sometimes work with users in order to add support for new phones, this
means sending them special test versions (I edit the test version in
version.py), do you think that this new source control will allow me to
baseline these test versions, I have lost code on occasion, so this would be
useful.

I do want to automate grabbing version number and other unique conditions
out of the working tree information. Some of it can be obtained by
the keyword expansions and the rest can be grabbed at build time.
TortoiseSVN has a similar utility they use:
http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch06.html

Post by Simon C
Is there a way for me to use sourceforge to host test versions of bitpim?

The SourceForge release system is extremely manual, annoying and tedious
not to mention error prone. You are welcome to subject yourself to it :-)
I have been looking for a command line tool that will automate all this
that uses Python. That way I can trivially update from each build machine.
(I'd like to build on more Linux distros but won't until this file release
pain goes away.)

The closest I have found is releaseforge.sf.net but for some unfathomable
reason the author chose to make it a gui tool. SourceForge already gives
you crappy web pages - just changing them to a different gui is kinda
silly.

Roger

[Joe Pham]

Post by Roger Binns
I think we should move to Subversion ASAP.

That sounds good. I know nothing about Subversion so I have some reading to do. I also need to digest what Roger's proposing, and also thanks to Roger for doing the prep work.

-Joe Pham




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

[Simon C]

Post by Roger Binns
You would checkout /branches/simonc/foo and do whatever work
you wanted there. Then use svn merge to bring the changes
back to the trunk.

It sounds similar to continuus, a commercial system I have used. Each
developer had their own project instance.
Check out meant you created a new instance of the file/object but it was not
checked into the respository, there was no locking (like clearcase can do).
The advantage of putting the file into this state *before* you started work
on it was that others can see that you are working on it before they make
changes allowing better coordination between developers. You could also sync
a working file with the repository which served as a backup mechansim for
working files.

Post by Roger Binns

Post by Simon C
Is there a way for me to use sourceforge to host test

versions of bitpim?
The SourceForge release system is extremely manual, annoying
and tedious not to mention error prone. You are welcome to
subject yourself to it :-) I have been looking for a command
line tool that will automate all this that uses Python. That
way I can trivially update from each build machine.
(I'd like to build on more Linux distros but won't until this
file release pain goes away.)
The closest I have found is releaseforge.sf.net but for some
unfathomable reason the author chose to make it a gui tool.
SourceForge already gives you crappy web pages - just
changing them to a different gui is kinda silly.

I've been doing test versions by incrementing the "testver" in version.py.
Can you recommend any reading that shows how I would go about making these
available for download?
Can I do this with the developer role?

Simon

[Roger Binns]

Post by Simon C
It sounds similar to continuus, a commercial system I have used. Each
developer had their own project instance.

It isn't. What you are describing is how client state is managed.
In systems like Perforce, ClearCase and this one you mention, the
server tries to keep track of client state. Roughly speaking it
knows what you have checked out (in the CVS sense of the term)
and where on your client filesystem. That approach can give
good performance since most developers haven't modified most
of the files. Subversion gets the client to keep track of its
own state. The client keeps a lot of information locally to
make it more efficient. For example pristine copies of the files
are kept, so the 'svn diff' operation is performed locally.

What I have been describing the prior email is the policy for
branching and tagging naming. Read the svn book.

Post by Simon C
I've been doing test versions by incrementing the "testver" in version.py.

We will be able to use the revision number instead and get that
for free.

Post by Simon C
Can you recommend any reading that shows how I would go about making these
available for download?
Can I do this with the developer role?

How many people are you giving these builds to? The file release
system is really nasty to deal with.

If it is just one or two people then it will be way easier just to
email them the builds. If they can't accept large emails then
they can get gmail accounts. (I have plenty of invites.)

Roger

[Simon C]

Post by Roger Binns
I think we should move to Subversion ASAP. (Bucketloads of
other open source projects have). The SourceForge doc is at
the following link. (As a bonus there is also no time delay
for anonymous users. As a double bonus we'll never have to
whine at Joe for EOL issues again :-)

I don't know how much work doing it twice would be but if it is easy to
repeat can we do trial run for this, set up test repository, let us mess
with it for a few days (without any fear of screwing things up) and then cut
over for real?

Simon

[Roger Binns]

Post by Simon C
with it for a few days (without any fear of screwing things up) and then cut

It looks like the repository can be replaced with new content.
The biggest thing I would recommend is reading the book, all
of it:

http://svnbook.red-bean.com/

It won't take that long and you'll get a better understanding.
Basically Subversion is very like the philosophy of CVS but
with a namespace layout like Perforce. (Perforce is one system
I hate - the namespace is good but the mode of operation is
that you have to beg permission to do anything and the monumentally
bad design decision is that the server keeps track of the client
state.)

Roger

[Simon C]

Post by Roger Binns
How many people are you giving these builds to? The file
release system is really nasty to deal with.
If it is just one or two people then it will be way easier
just to email them the builds. If they can't accept large
emails then they can get gmail accounts. (I have plenty of invites.)

It is only two or three at any one time, I'll stick to using my free but
slow yahoo briefcase that sbc gave me.

Simon