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.
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?
CVS works the same way here.
(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?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol