[MLton] Vendor branches (for maintaining ckit, mlnlffi, etc... ports)

[Stephen Weeks]

Replying to an old thread ...

> Have you considered using vendor branches, see
> 
>   http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
> 
> for maintaining the various external library and tool ports to MLton?

I looked into this and think it would be a good way to go.  I've never
liked the patch approach that we use for ckit-lib, mlrisc-lib, and
smlnj-lib.  In fact, we should probably use them for mlnlffigen and
CML too.  It would be nice to have in our SVN a clean snapshot of the
code that we borrowed, so it would be easy to see what we changed and
what others changed if/when we borrow a new version.  Even if the only
thing we did is to remove SML/NJ extensions.  It would be much easier
to see what we did.

> one nice thing about using vendor branches would be that I could
> develop the extensions "as usual".  I wouldn't have to use any
> special patching techniques, take extra copies of the sources or
> remember not to use make clean.

This is a good argument.

> I'm actually in favor of migrating mllex and mlyacc from "branched" to 
> tarball/patch, since there aren't (many) target compiler dependent aspects 
> of these programs.

Blech.  I think all the same arguments apply here.  We would benefit
from knowing what we branched from, and benefit from using our usual
SVN tools to maintain our branch.

> Also, I find the tarball/patch category more transparently "honest" in an 
> open-source sense.  It is a lot easier for those browsing the code to 
> realize that these directories contain borrowed code.  I know the LICENSE 
> file makes this all pretty clear, but I rarely (if ever) read the LICENSE 
> files of other projects.

I don't buy this, and it seems to be your only objection to using
vendor branches (I didn't see any technical objections).  There is a
README, a LICENSE file, copyright notices at the top of every file, an
acknowledgement in our documentation, and SVN history, all of which
point to where the code came from.  I don't see any chance of
confusion, and certainly no dishonest intentions.  To me, this is
purely a technical decision of what makes our development run most
smoothly.