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

[Matthew Fluet]

> 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.  

I'm not convinced that the diff between SML/NJ's mlnlffigen & CML and 
MLton's give particularly useful information, especially in terms of 
merging future changes; nor in terms of recovering the development 
relationship between the SML/NJ version and the MLton version.  True, 
recovering that information would have required branching at the 
original development time.

 > 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.

I suppose.  But it's just a diff in another guise.

>> 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.

True.

>> 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.

I don't have any strong objections.  But it's pretty low on my priority 
list.