[Monotone-devel] Re: monotone evaluation in commercial project [long]

[Bruce Stephens]

Nathaniel Smith <address@hidden> writes:

[...]

> Sorry.  The trunk really will have a single changeset on it that
> summarizes all your changes; but next to it, there'll also be the
> full history of how you got there.
>
> Is being able to get at this history really so bad a thing?

Sometimes the history of how I got there isn't interesting, so having
it there is a cost for no benefit except potential confusion.  

That seems to be what Linus and others have been arguing in the couple
of articles I mentioned a few days ago.  It's good that developers use
an SCM to hack on things, and it's also useful to have a nice coherent
history of how code develops (in order that people can understand how
it got there).  

So I think the disagreement is whether it should be possible to remove
the messy stuff or whether one should just ignore it.

I'm not sure I care either way.  I think I'd like some way to mark
some revisions as uninteresting, so that some tools (such as
monotone-viz) could reliably ignore them.  I'm not sure exactly what
that would entail: maybe an extra cert on the first revision of a
boring branch, or something?

And then maybe a future monotone could pull but excluding the marked
revisions, or something.

Currently monotone doesn't seem to have a way to have throwaway
branches in the sense that Linus seems to be talking about, except by
generating and applying patches by hand.  I'm not sure whether or not
BitKeeper actually has such a feature, but presumably it does, or it
fakes it well enough that it seemed to.

[...]