Hmm …

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

> svn commit -m"Emergency fix of all bad lock creators" and you've committed to all branches simultaneously

??? in my book this commits only to the branch you're currently on (or the trunk).

> This is (inevitably) harder in any VCS that supports real branches (as opposed to the in-VCS copies that SVN does)
> and that has a distributed notion of ancestry (as opposed to a central server assigning revision numbers).

This is not true for a VCS that tracks merges. With git, you'd patch the first commit your fix could reasonably apply to, record the commit ID of that change, and then blacklist every build that does not have this ID as an ancestor. In other words, a one-liner.

Hmm …

Posted Nov 4, 2018 18:03 UTC (Sun) by farnz (subscriber, #17727) [Link] (3 responses)

There is no such thing as a branch in SVN; by convention only, the root of the repository contains three directories, "tags", "branches" and "trunk". You are quite at liberty to check out the root and thus have all branches plus all tags plus trunk in a single working copy, and to commit a single commit across branches, tags and trunk at once.

And your git one-liner misses the point; I have build r23456 on my system. Commit r23440 fixed the world. This is all the information I need to know precisely whether or not I have the fix. In contrast, in git, I need a full ancestry tree - how else do I know if product1-v2.1-12-gabcdef is ahead of or behind product2-v9.1-45-gdefabc?

Hmm …

Posted Nov 4, 2018 20:36 UTC (Sun) by smurf (subscriber, #17840) [Link] (1 responses)

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.

Hmm …

Posted Nov 7, 2018 13:53 UTC (Wed) by Wol (subscriber, #4433) [Link]

> There is no such thing as a branch in SVN; by convention only, the root of the repository contains three directories, "tags", "branches" and "trunk". You are quite at liberty to check out the root and thus have all branches plus all tags plus trunk in a single working copy, and to commit a single commit across branches, tags and trunk at once.

Problem is, there's no such thing as a root in git. That's the whole point of a DVCS :-) The only reason Linus' tree is the root for linux is that everybody agrees that it is.

Having worked with Visual Sourcesafe, and with git, git is so much simpler because you're not stepping on other peoples' toes all the time :-)

Cheers,
Wol