[MLton] Vendor branches (for maintaining ckit, mlnlffi, etc...
ports)
Stephen Weeks
sweeks at sweeks.com
Wed Dec 13 12:31:28 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. 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.
More information about the MLton
mailing list