Debian version of MLton

[Matthew Fluet]

> You are pointing out two problems that I agree with.  However, you are ignoring
> the tremendous productivity benefits that Matthew and I have observed (new to
> me, maybe not to Matthew) over the last 5 weeks since switching to CVS.

I agree.  MLton is the largest project I've worked on with CVS, and I
think it's working great.  I think it will be really helpful after I head
back to Ithaca.

> Well, I'll have to try CVS and see if I change my mind, but I just don't see
> how it can be a saving since you can always keep different versions around
> on your own machine any way.

Yes, but with CVS, you don't need to.  I've pretty much dropped my
versions directory, because I can recreate pretty much any intervening
version whenever I want.  And I found branching off the new-codegen and
then merging it back in to be a very effective way of staying current with
everything else and having a place to commit my local changes.  Probably
the biggest benefit is that CVS will automatically merge in benign
changes.  For example, last year when I was working on MLton, I would have
one directory with my changes; when I was ready to send something to
Steve, he'd have to post his snapshot of the sources, I'd do diffs against
them, look through the files and port in any of his changes, do diffs
again, and finally package up what really changed.  And, presumably, Steve
had to something similar on his end to take care of his intervening
changes.  Now, I just do cvs update ; cvs commit, and, barring any major
conflicts, I'm done.  And, best of all, I can happily reformat code to my
heart's content and just check it in without Steve ever noticing. ;)

BTW, what's the issue with CVS not preserving time-stamps?  When I do a
fresh checkout, I certainly don't get everything with a now time.  Do you
just object to the fact that if I change a file Monday, commit it on
Tuesday (with no intervening changes), and do a fresh checkout on
Wednesday, that the file has a time-stamp from Tuesday?  I don't see how
you could do anything else than saying that the modified time of a file is
the last time it was committed and reasonably support simultaneous
modifications to the same file.  E.g., given file X, I change it on
Monday, Steve makes a non-conflicting change on Tuesday, Steve commits on
Wednesday, and I commit on Thursday.  What's the right time to give to the
file?  Thursday seems fine to me; I think of the "semantics" of commit not
so much as telling cvs to copy my file to the repository, but rather as
asking cvs to make a series of changes based on my file (like e-mailing a
bug fix along the lines of "change line n of x.fun from XXX to YYY" to
Steve; x.fun's time stamp is when Steve makes the change, not when I make
the change.)