Re: Alternative DVCS to git: hg?

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

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 ...

> 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.