-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/21/2011 10:44 AM, "Martin v. Löwis" wrote: >> My understanding is that svn does not detect fast forwards, only lack >> of conflicts, and therefore in case of concurrent development it is >> possible that the repository contains a version that never existed in >> any developer's workspace. > > I can't understand how you draw this conclusion ("therefore"). > > If you do an svn up, it merges local changes with remote changes; > if that works without conflicts, it tells you what files it merged, > but lets you commit. > > Still, in this case, the merge result did exist in the sandbox > of the developer performing the merge. Subversion never ever creates > versions in the repository that didn't before exist in some working > copy. The notion that it may have done a server-side merge or some > such is absurd.
It does so at the *tree* level, not at an individual file level. 1) svn doesn't require you to run 'svn up' unless there is a direct change to the file you are committing. So there is plenty of opportunity to have cross-file failures. The standard example is I change foo.py's foo() function to add a new mandatory parameter. I 'svn up' and run the test suite, updating all callers to supply that parameter. You update bar.py to call foo.foo() not realizing I'm updating it. You 'svn up' and run the test suite. Both my test suite and your test suite were perfect. So we both 'svn commit'. There is now a race condition. Both of our commits will succeed. (revisions 10 and 11 lets say). Revision 11 is now broken (will fail to pass the test suite.) 2) svn's default lack of tree-wide synchronization means that no matter how diligent we are, there is a race condition. (As I'm pretty sure both 'svn commit' can run concurrently since they don't officially modify the same file.) 3) IIRC, there is a way to tell "svn commit", "this is my base revno, if the server is newer, abort the commit". It is used by bzr-svn to ensure we always commit tree-wide state safely. However, I don't think svn itself makes much use of it, or makes it easy to use. Blindly merging in trunk / rebasing your changes has the same hole. Though you at least can be aware that it is there, rather than the system hiding the fact that you were out of date. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HMxoACgkQJdeBCYSNAAMaewCfW3DK8hW4hBKOA+5zbyaxyptH MMQAoKGw2uWUWafBK2+Jl5A6XMK+0z9f =5R0+ -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com