[MLton] Vendor branches (for maintaining ckit, mlnlffi, etc...
ports)
Matthew Fluet
fluet at tti-c.org
Wed Dec 13 20:20:32 PST 2006
> 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.
More information about the MLton
mailing list