Re: Reverting -current by date.

On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote:
> On Wed, Nov 20, 2019 at 10:39 AM bob prohaska <fbsd_at_www.zefox.net> wrote:
> 
> > From time to time it would be handy to revert freebsd-current to
> > an older, well-behaved revision.
> >
> > Is there a mechanism for identifying revision numbers that
> > will at least compile and boot, by date?
> >
> 
> Almost all of them will compile. Almost all of those will boot. While some
> build breakage sneaks through, the default assumption is that it's good.
> That's certainly been my experience randomly updating to -current. There's
> some that are more or less performant, mind you, and some that are more or
> less stable, it is true. But the overwhelming vast majority will compile
> and boot, at least for amd64. I have issues less than 1% of the time when
> updating to whatever is current at the moment I fancy an update.
>

Are commits that depend on one another somehow grouped in a single revision?
 
> There's some hardware that gets broken from time to time, but we don't
> track that specifically. And non-amd64 architectures takes more care and
> planning as any build breakage for those platforms lasts longer, in direct
> proportion to how popular the platform is....
>

Point taken. I'm interested in aarch64, which puts me somewhat in the weeds.
 
> It's all in the commit logs. If you run -current you need to read them.
> They will also tell you almost always if you pick revision X if there was a
> subsequent fix that made things compile you should go with.
> 

I take it the strategy would be go back in the log to a rough date,
then browse forward in time looking for signs of major trouble. When
the commits turn minor/benign, select a revision from that timeframe.
 
> 
> Study the commit logs? I know I'm harping on that, but when things go
> wrong, that's what I do.
> 

I hoped for a more mechanical approach. For example, snapshots are 
generated from time to time. Presumably, they're vetted in some way
and knowing what revisions made it to the snapshot stage might be a
starting point. The snapshot server does not appear to contain that
information for earlier offerings. 


> Also -DNO_CLEAN builds help a lot if you're worried about it not even
> building, though from time to time you run into issues with a NO_CLEAN
> build due to a recent commit that wasn't appreciated at the time of the
> commit, but was later and fixed.
> 

Does -DNO_CLEAN behave sanely (and usefully) when going backwards in time?
I commonly use it for small forward steps, but time reversal is tricky 8-)

Thanks for replying!

bob prohaska