3 ms·

> No way to easily reverse of course. Revert to the previous version. Push as new version. Fixed? SVN was used widely and for years, prior to git. I remember t

> No way to easily reverse of course. Revert to the previous version. Push as new version. Fixed? SVN was used widely and for years, prior to git. I remember the biggest problem being expensive (full copy) branching.

layer8 5y ago
Creating branches is not expensive in SVN, because it’s copy-on-write (server-side). Maybe you mean switching the local working copy to a different branch?
- Supermancho 5y ago
  > Creating branches is not expensive in SVN, because it’s copy-on-write Copy on write is an expensive operation for branching. SVN repos that are multiple gigs, in size, are a pain to create branches for.
  - layer8 5y ago
    Not sure what you mean. Copy-on-write means that no actual copy is made initially. Branching is therefore almost instant in SVN and only requires minimal storage space. Only when you modify a file within the branch (or the original) does that specific file get copied (or rather, the diff of the modification gets stored). What is slow in SVN is switching to the branch client-side, because branches are always created server-side and you still need to synch the whole contents of the branch from server to client when switching (which works similar to a regular `svn update`).
    - Supermancho 5y ago
      I'm not sure what you mean either. I don't care what SVN does now, only what it did when companies abandoned it en-masse around SVN v1.6, since that's the context of my comments.
      - layer8 5y ago
        What I described is what SVN always did. Cheap copies due to COW was always a selling point for SVN. My point is whatever was slow for you wasn't due to COW.
      - adrianmsmith 5y ago
        SVN branches were always cheap copies, right from the original version of SVN. "svn cp http://.../trunk http://.../trunk http://.../branches/foo http://.../branches/foo" may not be the most concise command to type, but all it does is create a new item "foo" in a new revision, which references a previous item "trunk" in a previous revision. How many files/directories are under that doesn't affect how long the operation takes.

layer8 5y ago

Creating branches is not expensive in SVN, because it’s copy-on-write (server-side). Maybe you mean switching the local working copy to a different branch?

Supermancho 5y ago
> Creating branches is not expensive in SVN, because it’s copy-on-write Copy on write is an expensive operation for branching. SVN repos that are multiple gigs, in size, are a pain to create branches for.
- layer8 5y ago
  Not sure what you mean. Copy-on-write means that no actual copy is made initially. Branching is therefore almost instant in SVN and only requires minimal storage space. Only when you modify a file within the branch (or the original) does that specific file get copied (or rather, the diff of the modification gets stored). What is slow in SVN is switching to the branch client-side, because branches are always created server-side and you still need to synch the whole contents of the branch from server to client when switching (which works similar to a regular `svn update`).
  - Supermancho 5y ago
    I'm not sure what you mean either. I don't care what SVN does now, only what it did when companies abandoned it en-masse around SVN v1.6, since that's the context of my comments.
    - layer8 5y ago
      What I described is what SVN always did. Cheap copies due to COW was always a selling point for SVN. My point is whatever was slow for you wasn't due to COW.
    - adrianmsmith 5y ago
      SVN branches were always cheap copies, right from the original version of SVN. "svn cp http://.../trunk http://.../trunk http://.../branches/foo http://.../branches/foo" may not be the most concise command to type, but all it does is create a new item "foo" in a new revision, which references a previous item "trunk" in a previous revision. How many files/directories are under that doesn't affect how long the operation takes.