General steps

The most important step, the migration itself, is explicitly not taken from the SourceForge documentation, as this turned out to be lossy (several branches were not included in the migration for unclear reasons).

The migration will be done on Windows 10 using Windows Subsystem for Linux with Ubuntu, but these instruction should work on a 'real' Linux install.

Tools to install

Using sudo apt-get install:

cvs (to be able to process the CVS repository)

rcs (for parsing the log files using rlog)

git (obviously)

make (to 'install' cvs2svn)

In a suitable working directory, install the latest development version of cvs2svn (the last released version might run into problems with multi-line commit messages).

Authors

Git uses email addresses as the usernames of committers, while CVS uses just a username. We will first need to obtain all usernames from the repository, and then associate email addresses (and if possible, user names).

For this migration we will associate the original SourceForge usernames with their username@users.sourceforge.net email address. If users want to associate these commits with their GitHub user account, they will need to associate this email address with their GitHub account (as a secondary address)

Review the authors.txt and make changes were necessary (eg maybe some users indicated they want their commits associated with another email address, real names are not present in the source forge profile, etc).

Conversion of a module

Before conversion, make sure the local copy of the repository is up-to-date (using rsync). In the description below, I assume migrating the OdbcJdbc module to git project firebird-odbc-driver.

For our purpose we took a copy of the cvs2git-example.options from the cvs2svn folder created in Tools to install, and made the following modifications. Most of these changes can be used for conversion for all modules, but some settings are per module (or may need some tuning per module).

(optional) Set ctx.tmpdir to a name specific to the module being converted (eg r'/home/mark/repomigration/cvs2git-OdbcJdbc')

(optional) If you are missing branches, comment out ExcludeTrivialImportBranchRule(), as an example the OdbcJdbc module had a branch that was equal to the original initial commit of the CVS repository, and was therefor excluded by this heuristic

Uncomment the AutoPropsPropertySetter (and related lines) and point it to svn-eol-style.txt

Uncomment the MimeMapper and point it to mime.types

Uncomment the EOLStyleFromMimeTypeSetter

Add add from cvs2svn_lib.svn_run_options import SVNEOLFixPropertySetter to the import list at the start, and at the end of ctx.file_property_setters.extend add SVNEOLFixPropertySetter(), to normalize up line-endings (test carefully if you really want to do this)

Be sure to read through the options file documentation, there are some settings you might want to tune further (eg the settings in ctx.file_property_setters.extend for line endings, etc). The cvs2git default behavior leaves the content as originally stored in the CVS repository (aka 'treat everything as binary').

The settings of step 9 have no effect if SVNEOLFixPropertySetter() isn’t added. Be aware that this can introduce issues further down the road, like line-ending changes between commits depending on the platform and configuration of the contributor. This applies especially for files that are prone to require specific line-endings (eg Windows .bat files). It might advisable to add a .gitattributes after migration and update affected files a described on https://www.git-scm.com/docs/gitattributes/.

Deleting the unlabeled-* branches may lead to loss of history if those branches were never fully merged back in a still existing branch. However as they had their name deleted in CVS, it was likely that the branch was no longer important. Weigh your options carefully, and keep a backup of the CVS repository!

Verifying contents of repository (replace the firebird-odbc-driver and cvs2git-OdbcJdbc with your specific names):

The fb folder is a trimmed down version of a normal Firebird installation. It is possible that some of the DLLs in the plugins folder are not necessary (this may require tweaking firebird.conf), and error logging suggests it might be necessary to include ib_util.dll as well, but the example program works without it. If you need additional configuration, then you can include a firebird.conf.

By default Jaybird 3 is only able to use the pure Java implementation of the wire protocol. For Jaybird to be able to use Firebird Embedded, you need to do two things:

To actually use Firebird Embedded is then just a matter of specifying the right connection URL:

"jdbc:firebirdsql:embedded:" + getDatabasePath()

Be aware that with the default configuration, fbclient.dll will try the embedded engine, but if that doesn’t work (eg engine12.dll cannot be loaded), it will then try the localhost server. This behaviour can be changed by adding a firebird.conf with setting Providers = Engine12 (which will disable the Remote and Loopback providers).

Fixed: Specifying an unknown Java character set in connection property charSet or localEncoding was handled as if no connection character set had been specified, now we throw an exception that the character set is unknown. (JDBC-498)

Changed: Specifying a connection character set is no longer required, and will now default to NONE again, if system property org.firebirdsql.jdbc.defaultConnectionEncoding is not specified. (JDBC-502)

Jaybird 3.0 supports Firebird 2.0 and higher, on Java 7, 8 and 9. Basic Java 9 compatibility is provided through the Java 8 version of the driver.