15 ms·

The thing I miss most about Subversion was the involvement of the whole team. git is only for programmers. Subversion was for everyone: our graphic designers ha

The thing I miss most about Subversion was the involvement of the whole team. git is only for programmers. Subversion was for everyone: our graphic designers had no problem with it, our project managers had no problem with it, our dumbest QA people had no problem with it. Subversion is easily used by non-technical people. There are many GUIs for Subversion that make it drop-dead easy to use. And there were big productivity gains to be had by having the whole team using the version control system. git has cut the team in 2. The graphic designers no longer know how to commit their work, nor do the frontenders, nor do most of the project managers. In particular, when a conflict comes up, nobody knows how to resolve the conflict (with Subversion we had a simple rule: "If you get a conflict, save your work outside of the project, then "accept theirs full", then re-integrate your work. A pain, but non-technical people could manage it). Instead, all of those people now send their work to the programmers, via email or Dropbox, and they say "Please integrate this into the project". This increases the amount of work that the programmers have to do. We now use git for everything, because it seems like it is the thing to do, and it helps the programmers merge their work together. But the price is high: the loss of half the team, who can no longer use the version control system.

Surio 14y ago
Sigh... Tell me about it! This story and small variations on this story, I hear a lot from various sources! > We now use git for everything, because it seems like it is the thing to do, You nailed it. And IMO this current obsession with Git/Github is bordering on unhealthy. I really wish/hope this fad dies out fast!
- owenjones 14y ago
  What about it is unhealthy and what about it is a fad? What do you wish/hope to replace Git with? Also anecdotal, but the graphic designers at our company have no problem using Git.
  - TylerE 14y ago
    Mercurial? So much easier conceptually, the cmd line utility was written for actual humans, and it has sequential commit numbers.
    - ekimekim 14y ago
      Sequential commit numbers? How does that work with branching? Or other people's commits? eg. I commit #100, you commit #100, you pull my commit, now we have duplicate identifiers. Git commit ids are a hash of the commit content. This has very nice properties in that: - Ids are duplicate if and only if the commit is identical (the collision chance is so low it's not worth considering) - It's content-addressable And you can refer to it by any unique prefix, so it's not a pain to type out (and you should only rarely be typing out particular commits instead of branches or tags).
      - lucian1900 14y ago
        Mercurial has local sequential commit numbers. The hashes are of course what one must use when others are involved.
    - owenjones 14y ago
      Sure Mercurial is a valid and possibly better alternative, I'm just hesitant to call git's popularity an unhealthy fad.
    - jeffbradberry 14y ago
      I don't understand this obsession with sequential commit numbers. These may vary from repo to repo depending on your commit/pull history.
      - TylerE 14y ago
        Because bigger numbers mean later in time. If you see references to commits 143, 732, and 2021, you have some instant grasp on the ordering of those. acbe2f, 7624ab, bccc07 not so much.
  - silverbax88 14y ago
    Mercurial.
- homosaur 14y ago
  If people are using SCM for too many things instead of too few, then that's a major improvement. Git could be better, yes. I personally prefer Hg even though I almost never use it due to Git's ubiquity. But as far as switching to distributed SCM, we spent 2 or 3 years fighting to kill the crappy centralized SCM systems we were using and we'll go back to centralized over my dead body.. I'd rather deal with a less friendly distributed system than ever have to use SVN ever again and deal with all the merge nightmares.
- robertfw 14y ago
  While I'm not wild about all the eggs being in one basket, I find myself getting frustrated when code isn't on github, because I can't star/watch/track it from one central place. I use the star feature on github all the time to mark potentially useful/interesting libraries, and every now and then will browse through them to see which ones took off and which fizzled.
slurgfest 14y ago
You seem not to be aware that there are also several GUIs for git? The pain here is not because git is inherently harder, but because you'd gotten used to svn (including your conflict workaround) and I guess nobody wants to do the same learning for git.
- samspot 14y ago
  Having learned CVS, SVN, VSS, Clearcase, git, and Mercurial, I can say that git is inherently harder than all the rest.
- blablabla123 14y ago
  SVN is waaay simpler. SVN is basically commit -a/pull/push. And even these differ in behaviour and semantics. Recently I tried Tourtoise git and I came to the conclusion that a beginner will probably rather learn the cmd line version because he will otherwise loose code.
  - NateDad 14y ago
    In SVN you still have to update (and in fact, if you try to commit without updating, it'll complain at you). That's the same as git pull. So all that leaves is one extra step, the push.
  - walls 14y ago
    Try the Github app.
  - jlgreco 14y ago
    I have the (fairly unique, I suspect) perspective of someone who never had to extensively use SVN until recently (before git came around there was lots of Perforce and manually managing patches/tarballs). SVN is unbelievably more difficult. The entire conceptual process of merging/rebasing/reintegrating is so much more difficult in SVN than git that I really cannot understand how people cope. Branches in SVN are such a pain in the ass that feature branching becomes a nightmare barely even worth doing. I get migraines trying to keep straight what things in SVN make changes on the server and what things make changes locally only that I can sit on for a while. Being centralized seems to raise the stakes of just about every operation, whereas with git I can take it slow, get everything right, and not involve other people until I decide it is the right time to do so. A month-long stint of working with another team that uses SVN for some incomprehensible reason left me seriously considering seeing a doctor about some blood pressure medicine. I swear to the gods I would rather use quilt.
grey-area 14y ago
I've had far more pain with subversion than with git. Those .svn directories sprinkled everywhere are a pain, get deleted and cause problems when clients move folders around, and things like users renaming files to lowercase from uppercase caused a client's repository to get into an unusable state and was difficult to recover from - insanity! Having used SVN, I'd never willingly go back to it, particularly with clients involved. For git on the command line, I use day to day 4 commands aliased: alias status="git status" alias commit="git add --all .;git commit -a -m" alias pull="git pull --rebase" alias push="git push" So, typically status - find out what's going on pull - grab any changes from others and replay mine on top commit - add my files and changes push - at the end of the day send changes up to the server Occasionally I'll use stash or tag, which are also pretty simple and straightforward. Yes the command line UI could be improved, but it's not much harder than svn or cvs. This in particular I find curious: We keep things under control by maintaining detailed sample scripts for everyone to refer to. Why not set up a file with aliases in it if you are asking people to refer to cheat sheets? The basic commands as above are painfully simple, most people don't even need to branch and can get by just by pulling, committing and pushing, but branches aren't particularly complex in git either... For non-programmer clients, for any version control system I'd get them to use a GUI like GitX, and they'll never touch the command line - that's very similar to svn GUIs, and frankly I doubt they'd know the difference. It's high time this sort of version control was integrated into operating systems though - life would be a lot simpler if the Mac OS Finder for example had built in support for a common system like git with a user friendly front-end. I can't count the number of clients and colleagues who have made their own crude version control system by renaming files with version nos or initials to track changes - there has to be a better way.
- Pwntastic 14y ago
  I'm pretty sure the newest revisions of svn no longer use .svn directories
  - beefman 14y ago
    Since v 1.7, a single .svn directory in the root of the working copy.
antris 14y ago
> Subversion we had a simple rule: "If you get a conflict, save your work outside of the project, then "accept theirs full", then re-integrate your work. A pain, but non-technical people could manage it You can do this in git as well.

Surio 14y ago

Sigh... Tell me about it! This story and small variations on this story, I hear a lot from various sources! > We now use git for everything, because it seems like it is the thing to do, You nailed it. And IMO this current obsession with Git/Github is bordering on unhealthy. I really wish/hope this fad dies out fast!

owenjones 14y ago
What about it is unhealthy and what about it is a fad? What do you wish/hope to replace Git with? Also anecdotal, but the graphic designers at our company have no problem using Git.
- TylerE 14y ago
  Mercurial? So much easier conceptually, the cmd line utility was written for actual humans, and it has sequential commit numbers.
  - ekimekim 14y ago
    Sequential commit numbers? How does that work with branching? Or other people's commits? eg. I commit #100, you commit #100, you pull my commit, now we have duplicate identifiers. Git commit ids are a hash of the commit content. This has very nice properties in that: - Ids are duplicate if and only if the commit is identical (the collision chance is so low it's not worth considering) - It's content-addressable And you can refer to it by any unique prefix, so it's not a pain to type out (and you should only rarely be typing out particular commits instead of branches or tags).
    - lucian1900 14y ago
      Mercurial has local sequential commit numbers. The hashes are of course what one must use when others are involved.
  - owenjones 14y ago
    Sure Mercurial is a valid and possibly better alternative, I'm just hesitant to call git's popularity an unhealthy fad.
  - jeffbradberry 14y ago
    I don't understand this obsession with sequential commit numbers. These may vary from repo to repo depending on your commit/pull history.
    - TylerE 14y ago
      Because bigger numbers mean later in time. If you see references to commits 143, 732, and 2021, you have some instant grasp on the ordering of those. acbe2f, 7624ab, bccc07 not so much.
- silverbax88 14y ago
  Mercurial.
homosaur 14y ago
If people are using SCM for too many things instead of too few, then that's a major improvement. Git could be better, yes. I personally prefer Hg even though I almost never use it due to Git's ubiquity. But as far as switching to distributed SCM, we spent 2 or 3 years fighting to kill the crappy centralized SCM systems we were using and we'll go back to centralized over my dead body.. I'd rather deal with a less friendly distributed system than ever have to use SVN ever again and deal with all the merge nightmares.
robertfw 14y ago
While I'm not wild about all the eggs being in one basket, I find myself getting frustrated when code isn't on github, because I can't star/watch/track it from one central place. I use the star feature on github all the time to mark potentially useful/interesting libraries, and every now and then will browse through them to see which ones took off and which fizzled.

slurgfest 14y ago

You seem not to be aware that there are also several GUIs for git? The pain here is not because git is inherently harder, but because you'd gotten used to svn (including your conflict workaround) and I guess nobody wants to do the same learning for git.

samspot 14y ago
Having learned CVS, SVN, VSS, Clearcase, git, and Mercurial, I can say that git is inherently harder than all the rest.
blablabla123 14y ago
SVN is waaay simpler. SVN is basically commit -a/pull/push. And even these differ in behaviour and semantics. Recently I tried Tourtoise git and I came to the conclusion that a beginner will probably rather learn the cmd line version because he will otherwise loose code.
- NateDad 14y ago
  In SVN you still have to update (and in fact, if you try to commit without updating, it'll complain at you). That's the same as git pull. So all that leaves is one extra step, the push.
- walls 14y ago
  Try the Github app.
- jlgreco 14y ago
  I have the (fairly unique, I suspect) perspective of someone who never had to extensively use SVN until recently (before git came around there was lots of Perforce and manually managing patches/tarballs). SVN is unbelievably more difficult. The entire conceptual process of merging/rebasing/reintegrating is so much more difficult in SVN than git that I really cannot understand how people cope. Branches in SVN are such a pain in the ass that feature branching becomes a nightmare barely even worth doing. I get migraines trying to keep straight what things in SVN make changes on the server and what things make changes locally only that I can sit on for a while. Being centralized seems to raise the stakes of just about every operation, whereas with git I can take it slow, get everything right, and not involve other people until I decide it is the right time to do so. A month-long stint of working with another team that uses SVN for some incomprehensible reason left me seriously considering seeing a doctor about some blood pressure medicine. I swear to the gods I would rather use quilt.

grey-area 14y ago

I've had far more pain with subversion than with git. Those .svn directories sprinkled everywhere are a pain, get deleted and cause problems when clients move folders around, and things like users renaming files to lowercase from uppercase caused a client's repository to get into an unusable state and was difficult to recover from - insanity! Having used SVN, I'd never willingly go back to it, particularly with clients involved. For git on the command line, I use day to day 4 commands aliased: alias status="git status" alias commit="git add --all .;git commit -a -m" alias pull="git pull --rebase" alias push="git push" So, typically status - find out what's going on pull - grab any changes from others and replay mine on top commit - add my files and changes push - at the end of the day send changes up to the server Occasionally I'll use stash or tag, which are also pretty simple and straightforward. Yes the command line UI could be improved, but it's not much harder than svn or cvs. This in particular I find curious: We keep things under control by maintaining detailed sample scripts for everyone to refer to. Why not set up a file with aliases in it if you are asking people to refer to cheat sheets? The basic commands as above are painfully simple, most people don't even need to branch and can get by just by pulling, committing and pushing, but branches aren't particularly complex in git either... For non-programmer clients, for any version control system I'd get them to use a GUI like GitX, and they'll never touch the command line - that's very similar to svn GUIs, and frankly I doubt they'd know the difference. It's high time this sort of version control was integrated into operating systems though - life would be a lot simpler if the Mac OS Finder for example had built in support for a common system like git with a user friendly front-end. I can't count the number of clients and colleagues who have made their own crude version control system by renaming files with version nos or initials to track changes - there has to be a better way.

Pwntastic 14y ago
I'm pretty sure the newest revisions of svn no longer use .svn directories
- beefman 14y ago
  Since v 1.7, a single .svn directory in the root of the working copy.

antris 14y ago

> Subversion we had a simple rule: "If you get a conflict, save your work outside of the project, then "accept theirs full", then re-integrate your work. A pain, but non-technical people could manage it You can do this in git as well.