6 ms·

> branching encourages cutting a program into "independent features" But, you can choose not to branch then? I’m really confused about the trade offs of versi

> branching encourages cutting a program into "independent features" But, you can choose not to branch then? I’m really confused about the trade offs of version control. I can understand trade offs of branching strategies, but at its most fundamental (snapshots of your code at arbitrary times), I can’t think of any drawbacks?

tmn 2y ago
I’m working on a feature that is a moderate refactoring and extending of an existing feature. I’m in some sense taking extra burden by ‘sculpting’ my change out of the existing code and the working backwards to come up with the logically contained and discrete commits to get from where I started to where I want to go. I would be nice to just make my change without having to show it in a series of discrete steps. I’m not actually opposed to this standard, but trying to show one perceivable downside that op may be alluding to (I’m not actually sure?)
- deleted 2y ago
  [deleted]
- sethherr 2y ago
  Thats not version control, that’s something you’ve chosen to do with version control. You could just check in your code every night. And, vs not having those commits (even without messages) - what could possibly be the downside?
  - tmn 2y ago
    Maybe your confusion is in your assumption of what’s being discussed
    - sethherr 2y ago
      I’m discussing version control.
      - tmn 2y ago
        And everyone else is discussing behaviors that are down stream of version control
        drawfloat 2y ago
        But only if you choose to use them. I agree with the other commenter, it's very hard to see what trade offs there are to pressing a button to initialise a repo at the start, then committing any changes at the end of each session/intermittently so there's a copy of current progress somewhere? If the OP is referring to version control because they're needing to handle multiple branch types, switching between versions etc that is much more involved....but also makes it even harder to see how you can manage that by simply dropping version control entirely? From the article, it does seem like it's not about any sort of specific feature they use, but rather the sheer basic "save versions of code" aspect of VC: "Version control kept me attached to the past" To go back to an earlier comment, this honestly sounds like burnout to me if you're having temporal anxiety from saving code.
        arthens 2y ago
        If it's your personal project, you are in charge of deciding which "behaviors that are down stream of version control" you want to adopt. If you are applying unnecessarily complex processes for a given project, that's on you.
  - tmn 2y ago
    This is all in a professional environment requiring code review for actual submission. I need to follow this process to actually deliver
    - sethherr 2y ago
      This sounds like you’re discussing code review and coding standards, not version control.
xelxebar 2y ago
You're, perhaps unintentionally, moving the goalposts a bit. "Version control" doesn't just mean database of code snapshots. It simultaneously connotes all the related functions and development processes we have around version control. Are you familiar with the artistic practice of adding "artificial" constraints in order to promote creativity and productivity? See Gadsby, the novel written without using the letter "e", or anything produced by Oulipo. The point is that we have a superabundance of choice with software architecture and programming tools. One subset of those tools comprises things provided by version control. Give yourself a version control-less, limited development environment and see how it influences the way you think about and practice coding. There will be sharp edges, but if you give it an honest attempt, you will also very likely discover novel and better ways of doing more with less. There are many things you can try. Disable syntax highlighting in your editor; try exclusively using a line editor such as ed; flatten your codebase into a single directory; code everything in a single file; organize your data structures to minimize pointer chasing; support extreme cross-platform compatibility (10 OSes?); write platform-independent code using "only assembly" (a la Forth, sectorlisp, or whatever); write a thing and then nuke and rewrite 5 times; etc. IMHO, value in the above is most easily discovered by retaining a strong introspective eye throughout your personal development process. Where are the pain points? What processes force you to think about non-end goal issues? When does coding feel the most glorious? When did you have the deepest insights? Blah blah blah.
- arthens 2y ago
  > You're, perhaps unintentionally, moving the goalposts a bit. "Version control" doesn't just mean database of code snapshots. It simultaneously connotes all the related functions and development processes we have around version control. Not OP, but I'd argue you are the one moving the goalpost here. If someone says they are not using "version control", I'm going to assume that they are not using git (or similar) at all. Any other meaning would be so arbitrary to be almost useless. No one can guess where you draw the line in the sand between "I'm not using any version control tool" to "I'm technically using a version control tool but I'm not doing version control because I don't do X,Y,Z". I personally can't imagine writing any non trivial piece of code without using git. Even in its more basic form, the advantages are overwhelming. But at no point of my 20+ years of development I've ever applied the same rigorous version control rules of professional environments to my personal projects. At best I've used branches to separate features (rarely, and mostly when I got tired of working on a problem and wanted to work on a different one for some time), and PRs to have an opportunity to review the changes I made to see if I forgot to do something. At "worst" I simply used it as a daily snapshot tool (possibly with some notes about what's left to do) or as a checkpoint after getting something complicated working. If the author has finally figured out rigorous source control can be unnecessary and counterproductive on small projects - good on them! But if that's the case then say that. Calling the fine tuning of which process you want (or don't want) to use "no version control" is just misleading.

tmn 2y ago

I’m working on a feature that is a moderate refactoring and extending of an existing feature. I’m in some sense taking extra burden by ‘sculpting’ my change out of the existing code and the working backwards to come up with the logically contained and discrete commits to get from where I started to where I want to go. I would be nice to just make my change without having to show it in a series of discrete steps. I’m not actually opposed to this standard, but trying to show one perceivable downside that op may be alluding to (I’m not actually sure?)

deleted 2y ago
[deleted]
sethherr 2y ago
Thats not version control, that’s something you’ve chosen to do with version control. You could just check in your code every night. And, vs not having those commits (even without messages) - what could possibly be the downside?
- tmn 2y ago
  Maybe your confusion is in your assumption of what’s being discussed
  - sethherr 2y ago
    I’m discussing version control.
    - tmn 2y ago
      And everyone else is discussing behaviors that are down stream of version control
      - drawfloat 2y ago
        But only if you choose to use them. I agree with the other commenter, it's very hard to see what trade offs there are to pressing a button to initialise a repo at the start, then committing any changes at the end of each session/intermittently so there's a copy of current progress somewhere? If the OP is referring to version control because they're needing to handle multiple branch types, switching between versions etc that is much more involved....but also makes it even harder to see how you can manage that by simply dropping version control entirely? From the article, it does seem like it's not about any sort of specific feature they use, but rather the sheer basic "save versions of code" aspect of VC: "Version control kept me attached to the past" To go back to an earlier comment, this honestly sounds like burnout to me if you're having temporal anxiety from saving code.
      - arthens 2y ago
        If it's your personal project, you are in charge of deciding which "behaviors that are down stream of version control" you want to adopt. If you are applying unnecessarily complex processes for a given project, that's on you.
- tmn 2y ago
  This is all in a professional environment requiring code review for actual submission. I need to follow this process to actually deliver
  - sethherr 2y ago
    This sounds like you’re discussing code review and coding standards, not version control.

xelxebar 2y ago

You're, perhaps unintentionally, moving the goalposts a bit. "Version control" doesn't just mean database of code snapshots. It simultaneously connotes all the related functions and development processes we have around version control. Are you familiar with the artistic practice of adding "artificial" constraints in order to promote creativity and productivity? See Gadsby, the novel written without using the letter "e", or anything produced by Oulipo. The point is that we have a superabundance of choice with software architecture and programming tools. One subset of those tools comprises things provided by version control. Give yourself a version control-less, limited development environment and see how it influences the way you think about and practice coding. There will be sharp edges, but if you give it an honest attempt, you will also very likely discover novel and better ways of doing more with less. There are many things you can try. Disable syntax highlighting in your editor; try exclusively using a line editor such as ed; flatten your codebase into a single directory; code everything in a single file; organize your data structures to minimize pointer chasing; support extreme cross-platform compatibility (10 OSes?); write platform-independent code using "only assembly" (a la Forth, sectorlisp, or whatever); write a thing and then nuke and rewrite 5 times; etc. IMHO, value in the above is most easily discovered by retaining a strong introspective eye throughout your personal development process. Where are the pain points? What processes force you to think about non-end goal issues? When does coding feel the most glorious? When did you have the deepest insights? Blah blah blah.

arthens 2y ago
> You're, perhaps unintentionally, moving the goalposts a bit. "Version control" doesn't just mean database of code snapshots. It simultaneously connotes all the related functions and development processes we have around version control. Not OP, but I'd argue you are the one moving the goalpost here. If someone says they are not using "version control", I'm going to assume that they are not using git (or similar) at all. Any other meaning would be so arbitrary to be almost useless. No one can guess where you draw the line in the sand between "I'm not using any version control tool" to "I'm technically using a version control tool but I'm not doing version control because I don't do X,Y,Z". I personally can't imagine writing any non trivial piece of code without using git. Even in its more basic form, the advantages are overwhelming. But at no point of my 20+ years of development I've ever applied the same rigorous version control rules of professional environments to my personal projects. At best I've used branches to separate features (rarely, and mostly when I got tired of working on a problem and wanted to work on a different one for some time), and PRs to have an opportunity to review the changes I made to see if I forgot to do something. At "worst" I simply used it as a daily snapshot tool (possibly with some notes about what's left to do) or as a checkpoint after getting something complicated working. If the author has finally figured out rigorous source control can be unnecessary and counterproductive on small projects - good on them! But if that's the case then say that. Calling the fine tuning of which process you want (or don't want) to use "no version control" is just misleading.