Hmm …

Posted Nov 4, 2018 20:36 UTC (Sun) by smurf (subscriber, #17840)
In reply to: Hmm … by farnz
Parent article: Apache Subversion 1.11.0 released

Sure I can check out everything at once. But (a) people usually don't work that way, (b) that also means that I can break everything at once. Guess what I, wearing my management hat, don't want to enable people to do – there's a reason we now have CI systems that run mandatory test suites before allowing anybody to check their "bug fix" into the release or CD branch.

Yes, you need an ancestry tree (not a full one – just one that goes back to the parent of the bugfix) if you do this with git. Surprise: You are most likely to already have it. In any case, there are other ways; one no-brainer method is an entry in a BUGS_FIXED file you'd check. Another would be a test suite that actually verifies that the bug is (and stays) gone.

Hmm …

Posted Nov 5, 2018 8:18 UTC (Mon) by farnz (subscriber, #17727) [Link]

Sure, people don't normally work that way - but in special cases, you can do that if you have to.

And I'm surprised that you think that ordinary customers on the phone have the test suites, a full ancestry tree and the ability to query that tree. That's not my experience anywhere - and in the sort of place where you fix all branches at once, you probably also have customers with special case branches with a per-customer fix on it. In that case, a BUGS_FIXED file isn't helpful - it'll cover all the cases you've thought about, but not the special cases.

Also, this isn't about whether or not this is good practice (small shops do all sorts of things that aren't good practice!) - it's whether or not there's anything that git can't do that SVN can. This is something that SVN can do, partly by virtue of not being as complete a VCS, that git can't do.