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

[Nick Coghlan]

On Mon, Mar 21, 2011 at 7:44 PM, "Martin v. Löwis" <martin at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia