On Wed, 17 Apr 2019 at 06:33, Johnny Billquist <bqt%update.uu.se@localhost> 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 ...