As announced on the XML Graphics General mailing list I'd like to call
for a vote on the migration of both Batik and FOP to Subversion.

There are two main reasons for this move:

- Over on the XML Graphics mailing list we are discussing and further
clarifying a plan to create a common space for components used by both
Batik and FOP subprojects. A migration to SVN prior to that would
greatly simplify the process because we can simply move files across
within the SVN repository. We would also maintain full history of the
files which would not be possible with CVS as there are separate
repositories for each subproject.

- The ASF Infrastructure team is increasing the pressure on ASF projects
to migrate away from CVS over to SVN as it simplifies maintenance and in
the long run they don't have to provide unix accounts for every
committer, further decreasing the maintenance efforts. It was hinted
that CVS will be discontinued within the ASF at the end of 2005. That's
not a fixed date but it's only a question of time. Those who follow the
infrastructure list will see that projects are migrating to SVN one
after another. If you want to have a look how many projects already
migrated go to [1]. We already have the XML Graphics website on SVN.

Of course, this has some consequences I don't want to hide:

- People have to get acquainted with a new tool. Like for CVS there is a
command line client which is the main client for SVN. There's already a
wide range of graphical clients even though many of them are not yet as
mature as the equivalents for CVS. On Windows, for example, there's an
excellent client called TortoiseSVN [2] which plugs into the Windows
Explorer. On Mac OSX there's SCPlugin [3] that plugs into Finder. On
Eclipse 3 there's at least one advanced SVN plugin [4]. Note that the
latter doesn't yet support all features that the CVS integration
provides but it's in a usable state for day to day work. You always have
the option to use the command-line client which is easy to learn and use.
A more comprehensive list of SVN clients can be found at [5]. The
documentation on SVN in genereal has very good quality [6].

- There have been stability problems until a few weeks ago. This was due
to ViewCVS which in certain situations caused connections to the
embedded Berkeley DB not to be closed (hanging processes). These
situation resulted in locks not being released. This is now resolved
(AFAIK) by ViewCVS accessing a read-only copy of the repository. But
there also has been bugfixing to improve the situation.

- Thomas DeWeese raised some concerns about the handling of binary files.
In my experience, SVN automatically detects binary files very reliably
and out-of-the-box. Additionally, you can configure the SVN client to
automatically set the correct MIME type for newly added files with a
certain extension.

As a personal statement, I can tell that I'm now using Subversion myself
for over a year and I've never regretted that choice. Last summer I
migrated the company I worked for until the end of last year to
Subversion and they are very happy with the results. It's not that I'm
not working there anymore because of that. ;-)

I understand that the Batik team is currently preparing for a release.
If this vote passes, we will time the migration accordingly not to
generate any trouble for this process, i.e. we would do the migration
after the Batik release.


I'm glad to answer any question you might have on the subject.

(This vote goes to the batik-dev and fop-dev mailing lists. I'll collect
the votes in 3 to 4 days and will present the results again to both

Jeremias Maerki

Reply via email to