[PD-dev] subversion (Fw: SOURCEFORGE.NET UPDATE - 2005-12-22 EDITION)

[Frank Barknecht]

Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:

> i wouldn't switch to the beta svn, but they're trying to get subversion
> running "stable" in march ... then i would switch ...
> 
> on the other hand i can understand hans, that learning subversion is
> very difficult which would delay pd's development by several monthes :-)
> it's a very difficult program to learn, especially when comparing it
> with something easy like cvs (just kidding) ...

Just for anyone , who has never used Subversion: It's practically
compatible to CVS and uses almost the same syntax, just replace
"cvs" with "svn" in your usual commands: 

$ svn update
$ svn commit
$ svn checkout
$ svn add
$ svn delete

It is well documented in the Subversion book:
http://svnbook.red-bean.com/ 

Svn has several advantages over CVS, especially the handling of
directory changes, copying or deleting of files (and dirs) so that
versioning and branching is easier and cleaner etc. 

It's definitely worth a look for every developer.

*However*: I think, a lot of the problems we still have with the
repository are not solved by just switching the versioning software.
Svn won't answer any of our open questions automatically, as in: 

How to do a common build system? How to handle the growing number of
developers, how to organize read/write permissions? How to deal with
Sourceforge delays (which might even get worse with SVN, depending on
how well Sourceforge manages the change)? [...]

Doing the CVS/SVN-switch might even introduce new problems, from
seemingly trivial things like having to update the documentation on
pure-data.org up to not so trivial stuff like importing the history of
the old repository and solving problems, that I cannot even think of
yet. 

Switching over to svn definitely will be a difficult operation, which
we must not hurry, although I, too, am in favour going for SVN at a
certain time.

But as this operation will be uncomfortable, I think, a different
question should be answered first: Should the repo. stay at
Sourceforge at all? Because if not, than doing the CVS->SVN switch at
SF would of course be superfluous. To answer that question, several
facts need to be taken into account, like the fact, that besides the
slow CVS, Sourceforge also has some advantages, for example the whole
infrastructure with user and project manager handling, bug tracker
etc.

All this is a very complex issue and we don't want to blindly jump on
the Cool New Thing, that is Svn on Sourceforge, forgetting about the
side effects and the future. 

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__