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

[Hrvoje Niksic]

On 03/21/2011 01:34 PM, Stephen J. Turnbull wrote:
>   >  Subversion never ever creates versions in the repository that
>   >  didn't before exist in some working copy.
>
> John Arbash-Meinel disagrees with you, so I think I'll go with his
> opinion

Besides, it's easy to confirm:

# create a repository and two checkouts:
[~/work]$ svnadmin create repo
[~/work]$ svn co file:///home/hniksic/work/repo checkout1
Checked out revision 0.
[~/work]$ svn co file:///home/hniksic/work/repo checkout2
Checked out revision 0.

# add a file to checkout 1
[~/work]$ cd checkout1
[~/work/checkout1]$ touch a && svn add a && svn commit -m c1
A         a
Adding         a
Transmitting file data .
Committed revision 1.

# now add a file to the second checkout without ever seeing
# the new file added to the first one
[~/work/checkout1]$ cd ../checkout2
[~/work/checkout2]$ touch b && svn add b && svn commit -m c2
A         b
Adding         b
Transmitting file data .
Committed revision 2.

The second commit would be rejected by a DVCS on the grounds of a merge 
with revision "1" never having happened.  What svn calls revision two is 
in reality based on revision 0, a fact the DVCS is aware of.

The message "committed revision 2", while technically accurate, is 
misleading if you believe the revision numbers to apply to the entire 
tree (as the svn manual will happily point out).  It doesn't indicate 
that what you have in your tree when the message is displayed can be 
very different from the state of a freshly-checked-out revision 2.  In 
this case, it's missing the file "a":

[~/work/checkout2]$ ls
b

This automatic merging often causes people who migrate to a DVCS to feel 
that they have to go through an unnecessary extra step in their 
workflows.  But once you grasp the "hole" in the svn workflow, what svn 
does (and what one used to take for granted) tends to become 
unacceptable, to put it mildly.

Hrvoje