5 ms·

> Therefore I suggested SubVersion This author has much to teach us about evil after all

by peteretep 5y ago

gmfawcett 5y ago
I think Subversion is fine for a centralized solution. True evil is spelled "C","V","S", but we do not speak its name.
- soperj 5y ago
  You speak as someone who has clearly never used PVCS.
- 2OEH8eoCRo0 5y ago
  Clearcase?
- kstrauser 5y ago
  I think Subversion is the best entry in a category of tools I never want to use again.
- erik_seaberg 5y ago
  At least CVS made it obvious that renaming a file wasn’t worth the effort. Subversion pretended to let you and then svnmerge.py took its revenge.
cactus2093 5y ago
That, plus a few sentences later: "Frankly, at the time, I did not understand much about branching strategies. It all seemed too complicated to me. I had hard times trying to fit the workflow in my head." I have no idea whose blog I'm reading here, but he doesn't exactly sound like someone whose opinion on version control and branching strategies should count for very much. Coming next week - a post about why X is the best programming language, from someone who hasn't bothered to learn any other programming languages!
- tdeck 5y ago
  Having worked with novice developers very recently I agree with the author here. The workflow of SVN (and similar) is much easier to understand and explain to folks who haven't used version control before. People tend to easily lose the thread when there's a local version of main/master, a remote version, and a local and remote version of their own branches, and they have to perform a whole host of commands to keep everything the way it should be. I often find even a simple workflow involves teaching multiple Git concepts that get in the way.
  - tharkun__ 5y ago
    I don't get how that's so complicated to be honest and your host of commands is literally 3. SVN had 2, big deal, especially when of those 2, commit can destroy all your work easily n SVN, while a very simple rule of git will allow you to never loose any work: Before you do "anything else", commit! By simple workflow I mean the simple workflow that mimmicks what you would've done with SVN (or CVS for that matter). Remember the holy wars of SVN over CVS? "What do you mean the entire repo has one version number instead of each file? Are you insane!" :) What git allows for are different workflows and some of them are probably harder to understand than others but very workable ones are really easy too and don't require a host of commands or a deep understanding as long as simple rules are followed. All of my last few new hires (juniors) can work without problems with our simple git workflow. FWIW, we use short lived branches per ticket that get PR'd into master. Master is always green and deployable (hourly). The branch is yours to do with whatever you want until you want to actually merge to master, at which point you have to squash and rebase from master. Some guys got bitten by not following the simple rules of "do one thing at a time" and "commit first". Luckily git refuses many actions if you have a dirty tree but people can get confused because they never read error messages. "Yes, yes I pulled and then ... and now it doesn't do what it's supposed to". Do one thing at a time works for most things in life and software development and rebasing from master while also squashing at the same time is just insane. Just do one of them first. Usually I find squashing first is easier as otherwise you might have to solve conflicts on intermediary commits that you wouldn't have in the first place with your squashed commit.

> Therefore I suggested SubVersion This author has much to teach us about evil after all

gmfawcett 5y ago

I think Subversion is fine for a centralized solution. True evil is spelled "C","V","S", but we do not speak its name.

soperj 5y ago
You speak as someone who has clearly never used PVCS.
2OEH8eoCRo0 5y ago
Clearcase?
kstrauser 5y ago
I think Subversion is the best entry in a category of tools I never want to use again.
erik_seaberg 5y ago
At least CVS made it obvious that renaming a file wasn’t worth the effort. Subversion pretended to let you and then svnmerge.py took its revenge.

cactus2093 5y ago

That, plus a few sentences later: "Frankly, at the time, I did not understand much about branching strategies. It all seemed too complicated to me. I had hard times trying to fit the workflow in my head." I have no idea whose blog I'm reading here, but he doesn't exactly sound like someone whose opinion on version control and branching strategies should count for very much. Coming next week - a post about why X is the best programming language, from someone who hasn't bothered to learn any other programming languages!

tdeck 5y ago
Having worked with novice developers very recently I agree with the author here. The workflow of SVN (and similar) is much easier to understand and explain to folks who haven't used version control before. People tend to easily lose the thread when there's a local version of main/master, a remote version, and a local and remote version of their own branches, and they have to perform a whole host of commands to keep everything the way it should be. I often find even a simple workflow involves teaching multiple Git concepts that get in the way.
- tharkun__ 5y ago
  I don't get how that's so complicated to be honest and your host of commands is literally 3. SVN had 2, big deal, especially when of those 2, commit can destroy all your work easily n SVN, while a very simple rule of git will allow you to never loose any work: Before you do "anything else", commit! By simple workflow I mean the simple workflow that mimmicks what you would've done with SVN (or CVS for that matter). Remember the holy wars of SVN over CVS? "What do you mean the entire repo has one version number instead of each file? Are you insane!" :) What git allows for are different workflows and some of them are probably harder to understand than others but very workable ones are really easy too and don't require a host of commands or a deep understanding as long as simple rules are followed. All of my last few new hires (juniors) can work without problems with our simple git workflow. FWIW, we use short lived branches per ticket that get PR'd into master. Master is always green and deployable (hourly). The branch is yours to do with whatever you want until you want to actually merge to master, at which point you have to squash and rebase from master. Some guys got bitten by not following the simple rules of "do one thing at a time" and "commit first". Luckily git refuses many actions if you have a dirty tree but people can get confused because they never read error messages. "Yes, yes I pulled and then ... and now it doesn't do what it's supposed to". Do one thing at a time works for most things in life and software development and rebasing from master while also squashing at the same time is just insane. Just do one of them first. Usually I find squashing first is easier as otherwise you might have to solve conflicts on intermediary commits that you wouldn't have in the first place with your squashed commit.