Re: SSD TBW
Lawrence D’Oliveiro <[email protected]>
| Newsgroups | comp.misc,sci.electronics.design |
|---|---|
| Organization | A noiseless patient Spider |
| Message-ID | <[email protected]> |
On Fri, 21 Aug 2026 23:07:48 -0700, Don Y wrote: > On 8/21/2026 9:54 PM, Lawrence D’Oliveiro wrote: >> >> On Fri, 21 Aug 2026 19:11:09 -0700, Don Y 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. 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. 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. > ... 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.