Re: Re: Too many heads?

Bruce Stephens wrote:
> > Consider a GNU style ChangeLog, for instance.  Every time anyone
> > changes any file, they also add lines to the changelog so that
> > there's some record of change for folks viewing the source tree from
> > outside the SCM system.  Or a NEWS file.  Or release notes.
> Presumably developers are going to be doing "monotone update" fairly
> often, and if you do "monotone update" where there are unmerged heads,
> it doesn't work, and displays an error.  
>
> As Richard Levitte commented, if you've got developers who continue to
> stumble on, somehow trying to make that continue to work, then the
> technology isn't your highest priority problem.
If I'm working remote on my laptop, and the project is large, then I may 
only be pushing my work, especially if the pull is lengthy across my 
thin wire.  If everyone is only pushing his work, then no one even sees 
that the central repository has multiple heads.
I agree that this is rapidly becoming a more and more remote corner case 
the more I understand it.
And I also agree that the failure mode when churn becomes too high will 
likely be quite noticable and call a halt to most work.  I see no reason 
why this scale boundary would be significantly different from other 
common free software tools like arch, subversion, etc.
I think it will still be earlier than clearcase dynamic views, but that 
seems inevitable in the absence of something like a filesystem based 
approach.
--rich