Re: Alternative DVCS to git: hg?

[Sad Clouds <cryintothebluesky%gmail.com@localhost>]

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.