[Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

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