4 ms·

You can't commit locally with either CVS or SVN, if I remember correctly? If the premise is "I can work on this locally", then you could do this since forever

You can't commit locally with either CVS or SVN, if I remember correctly? If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...

piva00 3y ago
You can't, and it was one of the major pain in the ass points allowing git and Mercurial to eat their lunches. Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation. Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell. VSS, CVS and SVN were ok to use when there were no other choices, Perforce was really good but very expensive, git and hg felt like the future when they showed up.
- xorcist 3y ago
  Well, we should be a little fair to cvs and svn. The C in cvs stands for "concurrent" as in the absence of locks. That how they differed from competing products. Lockfiles existed, but were intended to be mostly informative as they could easily be forced by anyone with write access, and were intended for special situations. The merge logic were pretty much identical for git and svn. The reason git is so much more advanced now is that is has improved a lot while svn doesn't see that much development anymore. I agree that git and hg felt like the future, and bazaar and arcs before them, but mostly because they represented another workflow very different from other products, not because of some specific technical reason. Version control is a network effect and you don't see the gains until everyone agrees on a common workflow. The rest is an implementation detail. OpenBSD is famous for being a strong culture around their cvs for example and it works for them.
- wdfx 3y ago
  For the thankfully very short period that I ever used SVN, I remember it being massively painful if the network was down. The local processes would just hang and then your entire workspace was pretty much unusable. Couple this with a single-core 32bit machine and less than 1G RAM and you're pretty much stuffed for any sort of productivity.
- denton-scratch 3y ago
  VSS was awful if you had a high-latency link to the server. VSS used a very chatty protocol, and was impossibly slow over (say) a transatlantic frame-delay link. I had to update our local copy of the repo overnight; sometimes the update just failed, and my team was dead in the water for several hours. A local SVN repository worked miles better. But house policy was VSS.
- AlexandrB 3y ago
  IIRC it wasn't just commits. You couldn't diff to previous versions offline either.
- astura 3y ago
  >Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation. Subversion? I used subversion for an entire decade at one job and never ran into this, in fact, I did not even know it was possible in subversion. When it happened with VSS before that we just got an admin to unlock the file(s) on the server. >Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell. I've just never had any issues with merging. shrug. >VSS, CVS and SVN were ok to use when there were no other choices I've used all three professionally and VSS never felt "okay" to use, it was very slow, super clunky, and prone to data loss and corruption. I would back up my files before commiting to VSS. You also just simply just can't view history of a folder if it was really big - the operation would just never complete. Basically, using VSS was just terrifying.
- beej71 3y ago
  My first job was at HP in the late 90s and I remember that "the merge" was an event for which significant time was reserved. It was heavily planned. I don't recall the system we used, though.
xorcist 3y ago
You can't commit to a server, obviously, but you can commit to a local directory. You would have needed set one up in advance however. Checkouts are sparse, in git terminology. Commit here approximates to a push in git terminology. The intended use is a little bit different. Normally you wouldn't have committed until you were really done with the work (and all reviews etc) since there is really no concept of a rebase. So a commit is really something you "commit" to. You work on the patch instead. Some of the difference is from the tools, but some of this is also due to the difference between a patch based vcs and content addressable one.
- neuromanser 3y ago
  How did you "commit locally" with Subversion twenty years ago? And if "local commits" were a thing, what was Svk for?
  - xorcist 3y ago
    svk is a tool to do exactly this. You can always copy the actual repo, you have read access to it after all. Something like svk vastly simplifies this workflow and can keep your local copy up to date. Keep in mind that the intended workflow with svn is to perfect a patch locally and commit when you are done. So something like svk is considered a special case, not an integral part of the workflow. git actively encourages you do split your work in separate commits using rebase. So there is a big difference in intended use, perhaps not as much in technical ability. Linus would likely have gone mad had he forced his workflow on svn.

You can't commit locally with either CVS or SVN, if I remember correctly? If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...

piva00 3y ago

You can't, and it was one of the major pain in the ass points allowing git and Mercurial to eat their lunches. Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation. Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell. VSS, CVS and SVN were ok to use when there were no other choices, Perforce was really good but very expensive, git and hg felt like the future when they showed up.

xorcist 3y ago
Well, we should be a little fair to cvs and svn. The C in cvs stands for "concurrent" as in the absence of locks. That how they differed from competing products. Lockfiles existed, but were intended to be mostly informative as they could easily be forced by anyone with write access, and were intended for special situations. The merge logic were pretty much identical for git and svn. The reason git is so much more advanced now is that is has improved a lot while svn doesn't see that much development anymore. I agree that git and hg felt like the future, and bazaar and arcs before them, but mostly because they represented another workflow very different from other products, not because of some specific technical reason. Version control is a network effect and you don't see the gains until everyone agrees on a common workflow. The rest is an implementation detail. OpenBSD is famous for being a strong culture around their cvs for example and it works for them.
wdfx 3y ago
For the thankfully very short period that I ever used SVN, I remember it being massively painful if the network was down. The local processes would just hang and then your entire workspace was pretty much unusable. Couple this with a single-core 32bit machine and less than 1G RAM and you're pretty much stuffed for any sort of productivity.
denton-scratch 3y ago
VSS was awful if you had a high-latency link to the server. VSS used a very chatty protocol, and was impossibly slow over (say) a transatlantic frame-delay link. I had to update our local copy of the repo overnight; sometimes the update just failed, and my team was dead in the water for several hours. A local SVN repository worked miles better. But house policy was VSS.
AlexandrB 3y ago
IIRC it wasn't just commits. You couldn't diff to previous versions offline either.
astura 3y ago
>Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation. Subversion? I used subversion for an entire decade at one job and never ran into this, in fact, I did not even know it was possible in subversion. When it happened with VSS before that we just got an admin to unlock the file(s) on the server. >Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell. I've just never had any issues with merging. shrug. >VSS, CVS and SVN were ok to use when there were no other choices I've used all three professionally and VSS never felt "okay" to use, it was very slow, super clunky, and prone to data loss and corruption. I would back up my files before commiting to VSS. You also just simply just can't view history of a folder if it was really big - the operation would just never complete. Basically, using VSS was just terrifying.
beej71 3y ago
My first job was at HP in the late 90s and I remember that "the merge" was an event for which significant time was reserved. It was heavily planned. I don't recall the system we used, though.

xorcist 3y ago

You can't commit to a server, obviously, but you can commit to a local directory. You would have needed set one up in advance however. Checkouts are sparse, in git terminology. Commit here approximates to a push in git terminology. The intended use is a little bit different. Normally you wouldn't have committed until you were really done with the work (and all reviews etc) since there is really no concept of a rebase. So a commit is really something you "commit" to. You work on the patch instead. Some of the difference is from the tools, but some of this is also due to the difference between a patch based vcs and content addressable one.

neuromanser 3y ago
How did you "commit locally" with Subversion twenty years ago? And if "local commits" were a thing, what was Svk for?
- xorcist 3y ago
  svk is a tool to do exactly this. You can always copy the actual repo, you have read access to it after all. Something like svk vastly simplifies this workflow and can keep your local copy up to date. Keep in mind that the intended workflow with svn is to perfect a patch locally and commit when you are done. So something like svk is considered a special case, not an integral part of the workflow. git actively encourages you do split your work in separate commits using rebase. So there is a big difference in intended use, perhaps not as much in technical ability. Linus would likely have gone mad had he forced his workflow on svn.