Re: SSD TBW

On 8/22/2026 4:34 PM, Lawrence D’Oliveiro wrote:

>>>> Also highlights differences (size/timestamp) between the two in
>>>> those cases when both have a file but they obviously differ I have
>>>> lots of cases of foo being renamed foo.old on my copy so the remote
>>>> foo doesn't overwrite it; then foo.older, foo.oldest, etc. -- a
>>>> place where versioning could be of benefit (but, some other repo
>>>> might have a different notion of foo that I will have to reconcile
>>>> with my instances.
>>>
>>> If these are text files, then that is the reason why software
>>> developers invented version control.
>>
>> You can use it with binary files, too, if you are careful.
> 
> It’s not about being “careful”, it’s about the usefulness of applying
> version control to such files.

The value of version control is to be able to recreate a particular
point-in-time of <whatever> you are controlling.

> With text files, you can use the “diff” command to narrow down exactly
> the parts that have changed. And the output of “diff” can be passed to
> “patch” to apply those changes to another copy of the original file.

You don't always have the ability to "create from source" (or from a
human-readable form) an item that you want to snapshot.  E.g., a PURCHASED
tool or component that you are using.

I commit typefaces, executables, images, etc. to the repository so I can
retrieve them in the state they existed when I was using them in a
version-controlled product.
> And here’s the fun part: you can use “patch” to apply *diffs from
> multiple sources to the same file*. Yes, there are occasions when this
> will lead to conflicts where different patches affect the same text
> lines, but the rest of the time, it works fine. This is the key to
> open-source collaborative development, being able to merge change
> submissions from multiple contributors.
> 
> With binary files, none of this really works.

Exactly.  But NOT being able to snapshot their state at a point in
time is even worse.  Or, having to invent another mechanism to
track their state "in parallel" with the other components
("Do I have the right versions of the non-text components
here to be able to restore the conditions in effect at said
point in time/history?")

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?  Or, just make a note that it doesn't
make sense to "diff" bitmaps (though I have tools that
will do that)?

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.

>> ... I use CVS. I have "imported" many legacy codebases that were
>> built with that as the VCS (some even use RCS or SCCS!). So, it's
>> easier to recover the history as well as reconstitute different
>> branches directly. (moving to git, svn, p4, etc. would mean I would
>> lose the ability to easily move back through the revision history to
>> reconstitute particular historical branches as that new VCS would
>> not have "seen" those versions as they existed at that time.)
> 
> The PostgreSQL folks went through exactly this issue. That didn’t stop
> them migrating to Git <https://lwn.net/Articles/409635/>. It’s all a
> matter of planning.

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?

Or, would I rather spend that time working on the project at hand?

My "project-based solution" is to simply snapshot the complete
system and save that as a VMDK.  Then, if I want to recreate the
state of the development effort at some future date, just copy
the appropriate VMDK to another "working" VMDK (so the preserved
VMDK is not altered by your new efforts) and move forward from
that point.

It is expensive in terms of disk space, but disk space is cheap.

[I've got 64T on my ESXi server and another few hundred TB
on the SAN if I am willing to access the store over the wire]