5 ms·

He's probably not unusual. I know git, but I refuse to use it until forced to. It's overly complicated and wastes my time. My SVN workflow works fine. My non-b

He's probably not unusual. I know git, but I refuse to use it until forced to. It's overly complicated and wastes my time. My SVN workflow works fine. My non-branch workflow: * Step 1: Do my work. Commit very often -- every time I implement a small granular piece. I keep the unit tests running. Other people see my commits immediately. This is simple, communication flows easily, and I'm not thinking about version control. My branch-based workflow. * Step 1: Create branch. svn cp ^/trunk ^/branches/feature-whatever && svn switch ^/branches/feature-whatever * Step 2: Do my work. Commit often. Other people see my commits immediately. This is simple. * Step 3: Run svn merge ^/trunk. Fix the occasional merge error caused by two people working on the exact same code at the same time. This is simple as long as I communicate with the team. It's easy to communicate with the team, because they all see my regular commits, and I see theirs, and so I know if we're stepping on any toes. * Step 4: Merge my work to trunk (possibly after review). svn switch ^/trunk && svn merge ^/branches/feature-whatever I hate the constant badgering from git proponents. They all want me to use a more complicated tool that doesn't offer any advantages to what I see as a simple, seamless workflow. I want my SCM to stay out of my way entirely. If I could avoid even thinking about it, I would. My job is to write code, not to spend a bunch of time juggling local/remote commits in a complex SCM tool. I've worked through the industry transitions from RCS to CVS, CVS to SVN, and introduction of SVK, Mercurial, darcs, and now git. Despite being a part of all those industry transitions, I've never seen such religious proselytizing and scorn from any SCM "proponents" as I've seen from git advocates.

voidr 14y ago
With git, you can basically do the same thing and a lot more. You could probably even alias your favorit SVN commands for easier learning. One of the main problems with SVN is that it works with files and not commits, you work on 3 files, commit your work, and SVN will let me only update 1 or 2 files, I think this is horrible and people do it... a lot. You are not forced to have local branches and commits that you didn't push to the main repository, but having them as options is a step forward. Also I can't imagine SVN working as good as git in the open source realm.
- flatline3 14y ago
  I'm aware that you can do the same things, just with a lot more user complexity. I prefer simpler tools if the complexity does not strike me as advantageous towards completing my primary task -- writing software. As for OSS, I'm much happier with the results of the PostgreSQL or FreeBSD development communication models than I am with the results of git/Linux style of development coordination. I think it's fair to judge by results.
  - voidr 14y ago
    I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot. If I want to I can alias git commit && git push, so that I don't have to type two commands to achieve something that can be done with one in SVN, I really don't see that as a big deal. The thing that bugs me about a lot of SVN users is that they are afraid for branching. A lot of them thing that updating specific files instead of the whole tree is a good thing. Sure there are some projects where SVN is good enough, but sometimes you just feel the need for the features of git. I think Linux is doing a lot better than FreeBSD. :)
    - flatline3 14y ago
      > I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot. Control, complexity. Same thing. I don't need control, I need the SCM to make my commits available to everyone immediately and get out of my way. Any time I spend twiddling the SCM system for asthetic reasons, or because I don't want to share my work until I'm ready for other people to see it, is wasted time that serves no code or communication advantage. We're software developers, not SCM operators. Git appeals to certain aspects of human nature that make the tool appealing, but are fundamentally negatively impacting on communication and the development process. > I think Linux is doing a lot better than FreeBSD. :) Not in terms of code quality, it's not. MySQL is also more popular than PostgreSQL, but there's no technical comparison.
antihero 14y ago
For the branch workflow: * Step 1: git checkout -b feature-whatever * Step 2: git commit -a (for all changes) OR or git add file1 file2; git commit (for specific files) OR git add -p; git commit (for staging specific changes within files) * Step 3: git fetch origin master:master; git merge master OR git pull origin master (while your feature is checked out) OR git fetch origin master:master; git rebase master (to replay your changes on top of master, which is cleaner and avoids a merge in history) * Step 4: git checkout master; git merge feature-whatever; git push origin master Is that really so much harder? Plus if you use the rebase option for Step 3 you don't get an ugly pointless merge.
- flatline3 14y ago
  Yes, that is more complex, especially when you start dealing with local vs local+remote branches. The SVN simple case is practically mindlessly simple, the branch case only slightly more involved. There are far, far, far fewer moving parts to worry about.
sophacles 14y ago
Fair enough you don't like it, and you probably don't need it. But if the team decides to use a tool, it is still kind of stupid, and just a little stubbornly unprofessional to cause them extra effort just to put up with your dislike of it - which is the case I'm describing. I mean I really dislike Visual studio and C#, but for reasons out of my control, we have to use it for a couple of projects. I could complain the whole time how it's not what I want, but instead I'm just doing it, because that's the job right now. I don't make the guy who doesn't like git (but is good at VS) come fix my environment or undo my mistakes every 3 days. My point was, the github svn support at least mitigates that scenario, whether or not it should happen.

voidr 14y ago

With git, you can basically do the same thing and a lot more. You could probably even alias your favorit SVN commands for easier learning. One of the main problems with SVN is that it works with files and not commits, you work on 3 files, commit your work, and SVN will let me only update 1 or 2 files, I think this is horrible and people do it... a lot. You are not forced to have local branches and commits that you didn't push to the main repository, but having them as options is a step forward. Also I can't imagine SVN working as good as git in the open source realm.

flatline3 14y ago
I'm aware that you can do the same things, just with a lot more user complexity. I prefer simpler tools if the complexity does not strike me as advantageous towards completing my primary task -- writing software. As for OSS, I'm much happier with the results of the PostgreSQL or FreeBSD development communication models than I am with the results of git/Linux style of development coordination. I think it's fair to judge by results.
- voidr 14y ago
  I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot. If I want to I can alias git commit && git push, so that I don't have to type two commands to achieve something that can be done with one in SVN, I really don't see that as a big deal. The thing that bugs me about a lot of SVN users is that they are afraid for branching. A lot of them thing that updating specific files instead of the whole tree is a good thing. Sure there are some projects where SVN is good enough, but sometimes you just feel the need for the features of git. I think Linux is doing a lot better than FreeBSD. :)
  - flatline3 14y ago
    > I don't feel any complexity, only more control. I admit though, that I started with git, which probably helped a lot. Control, complexity. Same thing. I don't need control, I need the SCM to make my commits available to everyone immediately and get out of my way. Any time I spend twiddling the SCM system for asthetic reasons, or because I don't want to share my work until I'm ready for other people to see it, is wasted time that serves no code or communication advantage. We're software developers, not SCM operators. Git appeals to certain aspects of human nature that make the tool appealing, but are fundamentally negatively impacting on communication and the development process. > I think Linux is doing a lot better than FreeBSD. :) Not in terms of code quality, it's not. MySQL is also more popular than PostgreSQL, but there's no technical comparison.

antihero 14y ago

For the branch workflow: * Step 1: git checkout -b feature-whatever * Step 2: git commit -a (for all changes) OR or git add file1 file2; git commit (for specific files) OR git add -p; git commit (for staging specific changes within files) * Step 3: git fetch origin master:master; git merge master OR git pull origin master (while your feature is checked out) OR git fetch origin master:master; git rebase master (to replay your changes on top of master, which is cleaner and avoids a merge in history) * Step 4: git checkout master; git merge feature-whatever; git push origin master Is that really so much harder? Plus if you use the rebase option for Step 3 you don't get an ugly pointless merge.

flatline3 14y ago
Yes, that is more complex, especially when you start dealing with local vs local+remote branches. The SVN simple case is practically mindlessly simple, the branch case only slightly more involved. There are far, far, far fewer moving parts to worry about.

sophacles 14y ago

Fair enough you don't like it, and you probably don't need it. But if the team decides to use a tool, it is still kind of stupid, and just a little stubbornly unprofessional to cause them extra effort just to put up with your dislike of it - which is the case I'm describing. I mean I really dislike Visual studio and C#, but for reasons out of my control, we have to use it for a couple of projects. I could complain the whole time how it's not what I want, but instead I'm just doing it, because that's the job right now. I don't make the guy who doesn't like git (but is good at VS) come fix my environment or undo my mistakes every 3 days. My point was, the github svn support at least mitigates that scenario, whether or not it should happen.