6 ms·

The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once

The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.

axod 17y ago
It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code (If that makes sense). For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.
- davidw 17y ago
  I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.
- jerf 17y ago
  "I want 1 codebase, developed linearly." Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end. Except you can trivially have multiple of these things going at a time. I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
  - axod 17y ago
    Yes I tried it for a day (Not long I agree). It looked like a reasonably copy of svn, but it didn't offer me anything. Let me restate: I do not like branches and use them very rarely. So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?
    - plinkplonk 17y ago
      "So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?" The ability to version control your project (even without branching you can checkin) when disconnected (from your network).
      - axod 17y ago
        Yes, I do this with svn easily enough (Local install of svn). Simple enough... Maybe that's a good selling point for people who aren't connected to the net much though,
        plinkplonk 17y ago
        "Yes, I do this with svn easily enough (Local install of svn). Simple enough..." Yeah Right :-P Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online? And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?
        axod 17y ago
        It's not really a use case I have. If I'm working, I have internet connectivity :/
ulrich 17y ago
This is something I don't fully understand. How does it make merging more easy? I tried mercurial some time ago and it gave me conflicts for very easy merges. While I like it very much as a local version control for myself this merging was really bad. Now its not unlikely that I made a mistake somehow. But why should merging be more easy with git/Mercurial than with SVN?
- cdavid 17y ago
  Before 1.5, svn had no real merge capability. In particular, it could not detect that you merged something already when merging a changeset. Also, the merge command effectively "squashed" everything - you could use svnmerge and co to get something a bit better, but the tools were very poor to say the least. Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits. Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.

axod 17y ago

It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code (If that makes sense). For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.

davidw 17y ago
I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.
jerf 17y ago
"I want 1 codebase, developed linearly." Then, when you want to commit your branch, rebase the branch from your master before merging. Then, when you merge, the patches will show up all in a row at the point you commit, as if they were all done in a row. Essentially, this is exactly what happens when you are working with subversion for a couple of days and then do several commits at the end. Except you can trivially have multiple of these things going at a time. I'm going to ask you a question: Have you actually tried git or anything for a significant period of time, like, at least a couple weeks? (Not just "yeah, 5 minutes.") If not, I'd point out that you're speculating about how git might affect workflow to people who actually know how git affects workflow, since they are living it. (And if so, you're not doing a great job of showing that you tried it.)
- axod 17y ago
  Yes I tried it for a day (Not long I agree). It looked like a reasonably copy of svn, but it didn't offer me anything. Let me restate: I do not like branches and use them very rarely. So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?
  - plinkplonk 17y ago
    "So, to the guy who hates branches, what does git offer me over svn (Which does all I need at the moment)?" The ability to version control your project (even without branching you can checkin) when disconnected (from your network).
    - axod 17y ago
      Yes, I do this with svn easily enough (Local install of svn). Simple enough... Maybe that's a good selling point for people who aren't connected to the net much though,
      - plinkplonk 17y ago
        "Yes, I do this with svn easily enough (Local install of svn). Simple enough..." Yeah Right :-P Obviously I meant if you were working on a project with its repository on a remote server. Assuming you want local version control (as you seemt o do, since you are locally installing svn) you'd maintain a separate local repository, maintain the same project under both, and synch them both when you get back online? And if you had two laptops say (apart from the remote server) , you'd maintain 3 repositories?
        axod 17y ago
        It's not really a use case I have. If I'm working, I have internet connectivity :/

ulrich 17y ago

This is something I don't fully understand. How does it make merging more easy? I tried mercurial some time ago and it gave me conflicts for very easy merges. While I like it very much as a local version control for myself this merging was really bad. Now its not unlikely that I made a mistake somehow. But why should merging be more easy with git/Mercurial than with SVN?

cdavid 17y ago
Before 1.5, svn had no real merge capability. In particular, it could not detect that you merged something already when merging a changeset. Also, the merge command effectively "squashed" everything - you could use svnmerge and co to get something a bit better, but the tools were very poor to say the least. Technically speaking, svn merge is more akin to cherry-pick in git/hg/etc..., where the "merged" commits are not recorded as such, but as totally new commits. Note also that bad svn merging capabilities are specific to svn, not to centralized VCS (perforce, etc...). It is not so much that DVCS are better than svn as much as svn worse than everything else.