On Mon, Mar 21, 2011 at 7:44 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > 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.
If you do an svn commit, and there are no files in conflict (or that require merging), svn will let the commit go through. It doesn't care if someone else may have updated *other* files in the meantime, so long as none of the files in the current commit were touched. Thus, if you don't do an svn up immediately before committing, you may get an implicit merge of orthogonal changesets on the server. svn will only complain if the changesets aren't orthogonal (i.e. "file x.y is not up to date"). This may break the buildbots if, for example, one commit changed an internal API in a backwards incompatible way, while the latter commit used that API (or vice-versa). hg broadens the check and complains if *any* files are not up to date on any of the branches being pushed, thus making it a requirement to do a hg pull and merge on all affected branches before the hg push can succeed. In theory, this provides an opportunity for the developer doing the merge to double check that it didn't break anything, in practice (at least in the near term) we're more likely to see an SVN-like practice of pushing the merged changes without rerunning the full test suite. Just accepting that, and filtering python-checkins to make it easier to skip over merge commits seems to cover the important points here, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
