What is a good use case for versioning a single file at a time? I was trying to find one for myself and coming up bare. Even the stated use case of “all those little scripts in your ~/bin directory” seems improved by the conventional approach of a dotfiles repo. Context matters, and every now and then I need to bundle a change to my .zshrc along with a script. Maybe HOWTOs are a good example, but what if you need to include a screenshot? And HOWTOs are intrinsically public; why would you not want to include authors in them in preparation for the time when the baton passes on?
After I saw @jcs’s video about amend, I thought about something like src. On the one hand, something far simpler than git would handle probably 90% of my needs for my solo projects. And my solo projects are most of what I do. (I’m a teacher who programs as a hobby, not a programmer.) But on the other hand, I contribute to FOSS projects, so I’d have to use git in those contexts whether I like it or not. With that in mind, I decided it was easier to stick with one thing. Switching back and forth seems like more trouble than it’s worth.
All of which to say, I wonder if this (or anything like it), however well designed and robust, can get much traction.
All of which to say, I wonder if this (or anything like it), however well designed and robust, can get much traction.
I’m not sure I will ever use src, for the reasons you mention. But I think that it actually doesn’t need traction. It’s less than 3000 lines of Python, documentation and help strings included.
Sure, there’s no need for a small project to be popular. I was just thinking that it’s a shame that people (myself included) may ignore something good because context switching is a pain. (Disclaimer: I haven’t tried src, but let’s assume it’s great for the sake of discussion.)
It’s less than 3000 lines of Python, documentation and help strings included.
But it uses either SCCS or RCS as a backend. For a simple wrapper around a separate source control system, 3000 lines seems like a lot.
For comparison, 9front’s git does not depend on an external version control system, includes a git server, and is only 3 times bigger – 8921 lines of code – as counted by:
I’d think this could also be implemented with git aliases and using a git repository as a version store. This way, advanced users can also fall back to standard git if needed.
This would have come in handy at the scientific publisher I worked for that kept every paper under RCS, which I honestly had trouble using after getting used to git.
This is very cool. I like the idea that you would track each file within the directory individually. You can track as many or as few files as you want, but you’ll only ever have the history of a given file laid out when viewing it.
What is a good use case for versioning a single file at a time? I was trying to find one for myself and coming up bare. Even the stated use case of “all those little scripts in your
~/bindirectory” seems improved by the conventional approach of a dotfiles repo. Context matters, and every now and then I need to bundle a change to my.zshrcalong with a script. Maybe HOWTOs are a good example, but what if you need to include a screenshot? And HOWTOs are intrinsically public; why would you not want to include authors in them in preparation for the time when the baton passes on?After I saw @jcs’s video about amend, I thought about something like src. On the one hand, something far simpler than git would handle probably 90% of my needs for my solo projects. And my solo projects are most of what I do. (I’m a teacher who programs as a hobby, not a programmer.) But on the other hand, I contribute to FOSS projects, so I’d have to use git in those contexts whether I like it or not. With that in mind, I decided it was easier to stick with one thing. Switching back and forth seems like more trouble than it’s worth.
All of which to say, I wonder if this (or anything like it), however well designed and robust, can get much traction.
I’m not sure I will ever use
src, for the reasons you mention. But I think that it actually doesn’t need traction. It’s less than 3000 lines of Python, documentation and help strings included.Sure, there’s no need for a small project to be popular. I was just thinking that it’s a shame that people (myself included) may ignore something good because context switching is a pain. (Disclaimer: I haven’t tried src, but let’s assume it’s great for the sake of discussion.)
But it uses either SCCS or RCS as a backend. For a simple wrapper around a separate source control system, 3000 lines seems like a lot.
For comparison, 9front’s git does not depend on an external version control system, includes a git server, and is only 3 times bigger – 8921 lines of code – as counted by:
I think that for a minimalist version control system, there’s likely a simpler approach that could work well.
I’d think this could also be implemented with git aliases and using a git repository as a version store. This way, advanced users can also fall back to standard git if needed.
This is for me and I will try it.
This would have come in handy at the scientific publisher I worked for that kept every paper under RCS, which I honestly had trouble using after getting used to git.
This is very cool. I like the idea that you would track each file within the directory individually. You can track as many or as few files as you want, but you’ll only ever have the history of a given file laid out when viewing it.