On Thu, 18 Apr 2019 22:40:45 +0200
Johnny Billquist <bqt%update.uu.se@localhost> wrote:
On 2019-04-18 22:04, Sad Clouds wrote:
On Thu, 18 Apr 2019 12:29:32 -0400
Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
When two fully tested commits hit the repo at the same time, and
the result is broken, who do I blame? Subversion? We can hardly
wave a finger at the developer who had the simple misfortune of
being second with their push?
This alleged design flaw in Subversion, is it something that you can
actually reproduce or are you just repeating something that you
heard from someone somewhere? You seem to be the only person to
come across the issue. Many people use Subversion concurrently and
they don't seem to be reporting such problems. So if the issue does
exist, as you claim, can you please give us a demonstration and
show us exactly how and when your files get corrupted?
The problem obviously exists/ It's trivial to understand.
Person A commits a change removing a macro from file A.
Person B commits a change which use the macro person A deleted.
Obviously person B did not do an update. And the two commits did not
touch the same file.
There is no problem, because what you described is how Subversion was
designed to work. The point is to allow multiple developers to make
concurrent changes. One of the alternatives is exclusive locks on the
entire repository, which is simply impractical.
If you want to guard against such chains of dependencies across
random files then the solution is quite simple - test, commit your
changes, run 'svn update' and re-run your tests again, fixing any issues
they find. Many companies have Continuous Integration (CI) jobs that run
build + test for every commit, so if you were the last person for such
a commit, pretty soon you'll be getting an email about a broken build.
Subversion is not breaking anything here, it's more to do with your
testing strategy, or the lack of it.