Options for working with SVN repo?

General Usage
1

I have been working on a wrapper library for an established project hosted on Sourceforge. I reached out to the maintainers and they said they would welcome a contribution, so now I am trying to decide the best course of action for housing the code.

I was originally going to make a new repo on my personal GitHub and treat it like another package, but after some thought I would prefer to just contribute to the existing structure rather than having to maintain something on my own.

The organization of the project to date has been to house tangential development work in folders under ~/branches, so I would get my own folder (something like ~/branches/ForestVegetationSimulator.jl). I have the code in the same format as a typical Julia package right now with everything in a src folder.

Is there a way I can set it up so that a user could add it with the package manager something like Pkg.clone()?

2

I don’t think there’s any way to allow an SVN repo to be used with Pkg.clone unless the server hosting that repo also provides a git interface. It looks like Sourceforge doesn’t offer that: SourceForge Support / Site Support / #12013 SVN, GIT synchronisation

Here’s one way you could handle the situation:

  1. Create a new Julia package ForestVegetationSimulator.jl
  2. In your package’s deps/build.jl file, download and build the open-fvs fortran code (BinDeps.jl or BinaryBuilder.jl will help)

Unfortunately, there’s another problem: I can’t find any licensing information anywhere on the open-fvs page, so it may not be legal for you to…well…do anything at all with it. I am not a lawyer and can’t give legal advice, but some caution may be in order.

So I guess step 0 is: clarify what the license for the open-fvs package is, and proceed accordingly.

3

Should be possible with the new package manager since it doesn’t care about git history at all. However this will very much be swimming upstream so you’ll be breaking new ground.

4

OK, I think that is what I was expecting based on my understanding. As an aside, the project is created/maintained by the US Forest Service. I am pretty sure the license thing has been brought up to them, but they don’t always move the quickest. I do know that there is no intention to change the project from the svn/sourceforge page to github.

After thinking on this some more, I remembered that I saw someone a while back was running a GH mirror, so in theory I could contribute to the main sourceforge page, wait for the GH mirror to refresh and have a user Pkg.add from that?

I am not sure if I need/want to go to the BinDeps/Builder level yet. There is already a build process to make the exe and dlls based on MinGW and Cmake with documentation available on the sourceforge wiki.

What I have been using as my expectation while working on this is a user has already compiled the fortran code into the dll based on the wiki instructions. I have a load function so user could point to where they have the dll.

function fvsLoad(fvsProgram,basedir="~/bin")
    const fvs = joinpath(basedir, fvsProgram)
    global lib = Libdl.dlopen(fvs)
end

Then all my functions reference lib in a ccall such as

function fvsAddTrees(in_dbh,in_species,in_ht,in_cratio,
                          in_plot,in_tpa,ntrees,rtnCode)

    ccall(Libdl.dlsym(lib,:fvsaddtrees_), Void,(
    Ref{Float32}, #in_dbh ....

As an ugly workaround, couldn’t someone just copy/paste the folder into where they have the Pkg.dir()?

5

A lot of those orgs have moved their fortran monoliths to git and github in the last couple of years, you could push them a little more. But at least its actually in revision control.

Can you just keep your julia wrapper on gihub and pull in the svn repo as a binary dependency? Seems a lot cleaner to me, its a scary world in that repo…