Re: SSD TBW

On 8/22/2026 6:19 PM, Lawrence D’Oliveiro wrote:
> On Sat, 22 Aug 2026 18:04:48 -0700, Don Y wrote:
> 
>> The value of version control is to be able to recreate a particular
>> point-in-time of <whatever> you are controlling.
> 
> Any backup/restore system can do that, surely.

That is time based.  You want to declare a "version" -- branch -- of
the development and capture THAT.

Do you happen to recall what DATE version 27.3.1204 was in effect?
VCS lets you deal with "time" as a history of a product/component
instead of as a mark on a calendar.

It also lets you address *pieces* of the product/component
instead of having to move everything to that point in "time".

E.g., I had to revise a PCB layout for a client -- who had
upgraded the layout tool (newer is better, right?).  Only
to discover that the new version couldn't read files that
the previous one had produced.

Should he uninstall the new version, find the previous version and
reinstall that?  Or, just retrieve it from the VCS (along with
required support files)?

The advantage of saving entire development system states is
you don't have to wonder what OTHER things affect the operation
of the tool that you need to access, again.

And, as they are so easy to call up -- and discard -- the
impact on your *current* system's state is minimalized;
once done with this retro activity, you can return to whatever you
were doing before that need arose.

> The specific value add of version control is being able to keep track
> of what has changed. And more than that, to be able to pursue multiple
> parallel lines of development, and be able to reconcile them later.
> This is particularly important for collaborative development, which is
> how a lot of open-source projects operate these days.
> 
> Why would you need to keep track of what has changed? Imagine getting
> a report of a bug that has appeared in a new release, that wasn’t
> noticed during development; there is a command called git-bisect, that
> comes with Git, that helps you track down the precise commit that
> introduced the bug.

Here's a photo of my back yard.  Here's another.  What has changed
(please indicate that in a human-friendly form).

Not everything is "source code".  Not every commit can be traced
back to specific actions:  first I took the photo.  then I enhanced the
contrast by 23%.  then I applied a filter that made all green tints
a bit darker.  then I cropped it to the final size.

Far easier to show before and after especially as there is no
guarantee that the "user" can determine which of these steps
needs to be changed -- all except the cropping are subjective.

>> E.g., I have hand-drawn the icons for the "HiFi replacement" I'm
>> making for my other half. Should I export those bitmaps as text
>> files just to be able to preserve them AS text, instead of bitmaps?
> 
> You should have drawn them as SVG. That gives you
> resolution-independent scaling, and it’s also a text-based format
> (actually XML).

I'm dealing with a *small* bitmapped display.  So, glyphs are on-the-order
of 5x7 arrays.  I don't want some tool to decide how to map the antialiased
pels to on/off states (which is all I can get from the display).  *I* want
to look at how each presents so I can evaluate the quality of the display
instead of leaving that to some tool to decide.
>> Sadly, UNIX assumes file type is completely indicated by a suffix on
>> a filename -- said suffix being under the control of the person who
>> selected the filename.
> 
> Not quite how it works <https://www.darwinsys.com/file/>.

file(1) is almost WORSE than using file extensions.  As with a Mac,
I (or an application) should be definitively declaring the form
and content of a file, instead of leaving that to something else to
deduce or declare (possibly incorrectly)

>> It's a matter of human resources. Do I want to replace one VCS with
>> another (at some amount of time, effort and risk), just to say I did
>> so? Will I be THAT much "better off" after having made the switch
>> than if I had continued using the system that had been in place when
>> those things were created?
> 
> If you want to encourage others to contribute to your project, then
> Git is the way to go.

The people having access to my sources (contributing) have no qualms
using the tools (compilers, preprocessors, VCS, etc.) that I've
put in place.  "It all works".  They are free to import the portions
of the codebase of interest to them, personally, and manage it with
whatever tools *they* choose.  I.e., ADOPT the codebase as their own.
They don't have to accept the constraints that I've put on the runtime,
can recode the algorithms in CLU, rewrite the comments in Esperanto,
etc.  It's THEIRS to do with as they want.

OTOH, if they want to keep abreast of MY efforts, then they have to
adapt to the tools that *I* choose.  No one is holding a gun to their heads.