"Martin v. Löwis" writes: > > 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").
A fast forward is a case where some ancestor of the workspace is the tip of the repository. When the tip is not an ancestor, it must contain changes not yet in the workspace. If a VCS does not check for fast-forward, then if those changes are in files not changed in the workspace, there will be no conflict, and in theory there could indeed be a silent server-side merge. QED, "therefore". This seems especially plausible for VCSes that allow only a subset of files to be committed/pushed. > 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 absent a really convincing argument otherwise. No disrespect to you intended, but John is an expert I've known for years. > The notion that it may have done a server-side merge or some > such is absurd. False, quite possibly; I'm not an expert on Subversion internals. Absurd, definitely not. CVS does it (and much worse, but it certainly does this too). > You make it sound as if you have never used subversion. These days, it's awful hard to avoid using Subversion. However, I have no experience with committing in Python, and I don't have that much experience that I can claim to be authoritative, nor have I managed a multiuser Subversion repository. _______________________________________________ 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