|
|
|
|
|
|
by paavoova
1632 days ago
|
|
|
I've noticed that people tend to have varying differences in their mental map of organization. If you view a codebase as largely monolithic with only a few states such as previous/backup, current, and future/editing, the addition of version control may not help workflow. Editing is always a rolling-release model, be it backwards or forwards (at least that's what I interpret from "there is kind of an active molten core that I have a much better working knowledge of" in the article.
If version control were introduced, you would now be tasked to actively divert workflow to the versioning software, such as when reverting commits, etc. You don't create a repo for trivial objects, such as a simple shell script you write for your personal desktop, so it's easy to see this applied to scale, especially with a single-person codebase like DF. For the script example, a file will typically have undo/revert history in an editor, which itself is a limited form of version control. So there obviously has to be some form of version control used by the author other than file copying, albeit not as explicit as git.
I think it's unfair to call it a mistake unless you're directly affected. In the 20 years of (solo?) development of DF, do you not suppose a rational person would adopt versioning were a lack thereof impacting them noticeably? So obviously it's a non-issue as far as scope of the codebase goes. |
|
|
But the real simple stuff usually starts out in my misc scripts folder. But that's more for filesystem organisation, not because creating a git repo has any (mental) overhead.
> In the 20 years of (solo?) development of DF, do you not suppose a rational person would adopt versioning were a lack thereof impacting them noticeably?
If they never got around to learning about version control, it's totally imaginable that they are sort-of rational, and that version control would have improved their lives.