On Wed, 17 Apr 2019 at 06:33, Johnny Billquist <[email protected]> wrote: > > On 2019-04-17 10:02, Andreas Krey wrote: > > On Wed, 17 Apr 2019 09:10:28 +0000, Johnny Billquist wrote: > > ... > >> Are you saying that subversion would interleave two commits? Commits in > >> subversion are supposed to be atomic. And each commit gets a > >> monotonically increasing commit number. Which also gives you in which > >> order the commits happened. > > > > Correct, but subversion does not guarantee that the commit you make > > is actually made on the revision in your sandbox. I can add an > > '#include <yours.h>', and all tests work locally, while you > > commit the removal of yours.h. I still can commit my change, > > resulting in a broken revision without any indication - or way > > to avoid that. > > But that is where I think this is correct. I can just as well also make > a change that depends on a local file that is not even in the > repository, and it will work fine for me, but it will fail for anyone > else who checks things out.
Try looking at it from the POV of developer #3 (or a test framework): they pull the upstream repo and find it doesn't build. Who do they blame? The "work around" is to somehow "encourage" all the developers to go through something like: - test - push - pull oh, "expletive", - hack - push - pull oh, "EXPLETIVE" .... sure, like that will work ... > As long as I'm making changes that don't conflict with other changes, > the VCS is fine. What you seem to be asking for is that the VCS should > have a semantic understanding of a commit, and notice if the > code/content make sense after a commit. Or what am I missing? No. Just the expectation that, after a successful push, what I have in front of me and in the repo are consistent. Some bonus commit hasn't magically been inserted before mine. > CVS works the same way here. Yes, subversion was designed to be a better CVS. CVS is a pretty low bar though. A bunch of shell scripts wrapping individual RCS files with only single-file locking (at some point things did get better, rewritten in C, directory locking, various attempts at making commits atomic, ...). > > (That 'svn log' won't even show my own commit afterwards > > (or yours before) is another one of svn's many idiosyncrasies.) > > I'm not following again. If I make a commit, I would assume it shows up > afterwards if I check the log for the file. Are you saying it won't? It shows up. But (from memory here), SVN wonders off and talks to the server and discovers there's a bonus commit that's been magically inserted before your change.
