Re: Reverting -current by date.

From: Julian Elischer <>
Date: Wed, 20 Nov 2019 15:11:39 -0800
On 11/20/19 12:02 PM, bob prohaska wrote:
> On Wed, Nov 20, 2019 at 11:18:41AM -0700, Warner Losh wrote:
>> On Wed, Nov 20, 2019 at 10:39 AM bob prohaska <> 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?
Unlike in the old CVS days,  yes, our commit rules require any
single commit to not break the build or system, which, as a corollary 
that people should commit all changes required to do so in a single 
>> 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.
basically yes. I usually do a (more or less) binary search, informed by
examination of the sources and commit history.
>> 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.
yes there are snapshots but they are more likely to be vetted for
compiling than for running successfully on your hardware.
>> 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-)
Good question.. that would depend on whether the source control 
program you use updates the timestamps of the files to be the time of  
commit or time of update.. I am pretty sure svn just uses the time 
that you ran the command. However SOMETIMES there are changes that are 
made to support forward migration that may not work well with 
backwards migration..  I tend to do several NO_CLEAN builds but every 
now and then  I'll do a full build if I've gone too far or if things 
seem a bit odd.
> Thanks for replying!
> bob prohaska
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""
Received on Wed Nov 20 2019 - 22:11:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC