Just wanted to add that we use Subversion with Eclipse (via subclipse,=20
under Debian GNU/Linux) for shared source code and it works well for us. =
like its model of using a directory metaphor for tagged or branched=20
versions (rather than treating branches as special things as in CVS).
Subclipse especially makes it easy to use SVN (if you use Eclipse). This =
is not to say there isn't any learning curve -- there is, as with most=20
tools -- but easy things are fairly easy to do once you get the sense of =
how it works, and most of the learning curve is about how to set things u=
or how to do merges rather than how to do basic things (e.g. update). I=20
also like that the documentation is available on line for free (even=20
though I bought the book anyway and read it pretty much cover to cover,=20
because I wanted to maintain a repository -- you don't need to read much =
to just use one).
The hardest thing I encountered conceptually was realizing how central th=
notion of a directory is to svn and what it means that "copies are cheap"=
and how some things are conventions (like "trunk, branches, tags"=20
directory layout, which really does make sense as a convention for most=20
setups). It also took me a while to really understand how easy it was to =
"switch" to a different version of the source code (like a tag or branch)=
and how the project directory name locally could be very different from=20
the remote project path (why it doesn't matter if you have an extra=20
"/trunk" in the remote path name). So there is some unlearning that needs=
to go on if you are used to other approaches.
However, I did also have some issues with server aspects of setting svn u=
an running. The svn server periodically refused to run as a service and=20
then woudl run again a couple minutes later; I'm still not sure how to=20
resolve that, other than running a server from a console (maybe there is =
some stale lock issue?), but I'm thinking that's a specific issue to my=20
configuration, not a general problem and I haven't noticed it since doing=
a recent upgrade to my entire system.
Overall, SVN is well worth any hassles encountered. Should any questions =
come up, feel free to ask me and I'm happy to share my limited expertise =
Anyway, I think moving Jython to svn would make it easier for more people=
in the future to contribute to Jython than continuing to use CVS.
It might also make it easier to manage having an older branch around (say=
Java 1.1 compatible, with only essential bugs fixed) while moving Jython =
forward assuming Java 1.4 or 1.5 support.
Frank Wierzbicki wrote:
> Hello Jython developers,
> The CPython developers have recently migrated from the sourceforge CVS
> repository to their own Subversion repository (svn.python.org). Also,
> Bill de h=D3ra and A.M. Kuchling have moved the Jython wiki onto the
> python.org servers and are about to move the website source to
> These events led me to see if A.M. Kuchling would be willing to help
> me move the Jython sources onto svn.python.org., and he has kindly
> offered to help me do this in a month or two. This will give the
> CPython folks enough time to work through any difficulties.
> Of course since I'm not the only Jython developer, I want to make sure
> this is what the Jython developer community wants.
> The CPython developer rational is here:
> My main goal is to rearrange the repository directory structure so
> that newcomers who are already familiar with other open source Java
> projects can easily orient themselves. By making the
> download/build/run experience friendlier -- especially for those that
> use an IDE -- it is more likely that developers out there will
> actually try fiddling with the Jython sources -- and hopefully some of
> them will become contributors.
> What does everybody think?