On Sun, Mar 20, 2011 at 5:05 AM, <skip at pobox.com> wrote: > Sorry, this workflow is still new and hugely confusing to me. To make a > simple edit to csv.rst I needed to do a couple pulls and merges, local > commits, resolve the same conflict multiple times, get rebuffed when I first > pushed because there was a tab in the file, and ask a question here. If > this is the typical route necessary to make even the simplest changes which > would have been a single commit with svn, my already meager rate of > contributions is likely to wither away to nothing. Note that some of that isn't unique to the Mercurial transition (specifically, the server side hook that complained about the whitespace change existed in SVN as well). One key difference that we could historically ignore with SVN is that it would happily accept changes from an out-of-date working copy, so long as the committed changes didn't alter any files that had also been updated on the head. In practice, this *did* mean a lot of commits did get rejected, since Misc/NEWS would often conflict. Mercurial's changeset based view of the world means it wants to know how the changesets relate to each other even when they affect different files, unlike SVN which would happily do an implicit merge (creating a state in the central repo that no developer has ever tested locally). So the full flow for a trunk commit in SVN was: svn update # change stuff svn commit -m "Whatever" # get rejected by server side hooks (e.g. changed files, bad whitespace) make patchcheck # fix whitespace issues svn update # get updated files # Resolve any conflicts, rerun relevant tests svn commit -m "Whatever" Mercurial isn't really all that different, but it's distributed nature means it want to keep track of even minor things like the local whitespace fixes and the merger of your changes with the other changes that were pushed since you started work. So the example above becomes something like: hg pull -u #change stuff hg commit -m "Whatever" hg push # get rejected by server side hooks (e.g. changed files, bad whitespace) make patchcheck hg commit -m "Fix whitespace" hg pull -u hg merge # Resolve any conflicts, rerun relevant tests hg commit -m "Merge with remote" hg push It definitely produces some additional noise on python-checkins, since things that would normally have been resolved privately by the developer before SVN accepted the commit are now being published to the mailing list. To help with that, I've personally split my python-checkins label into two: one which contains everything from the list, and another which filters out any messages with "merge" in the subject line. You may also find "hg outgoing" useful, since that will tell you all the changesets that a call to "hg push" will publish, rather than just the latest changeset as shown by "hg heads". Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4