Thanks for the example, Hrvoje.
Hrvoje> This automatic merging often causes people who migrate to a DVCS
Hrvoje> to feel that they have to go through an unnecessary extra step
Hrvoje> in their workflows. But once you grasp the "hole" in the svn
Hrvoje> workflow, what svn does (and what one used to take for granted)
Hrvoje> tends to become unacceptable, to put it mildly.
In the run-up to a release when there is lots of activity happening, do you
find yourself in a race with other developers to push your changes cleanly?
Suppose I am ready to check in some changes. I pull, merge, update. Run
the unit tests again. That takes awhile. Then I go to push only to find
someone else has already pushed a changeset. I then have to lather, rinse,
repeat. This might happen more than once, especially in the last few days
before an alpha (or the first beta) release. Historically, most of the
churn in Python's code base occurs at that time.
I don't know how likely this would be to happen, though I can imagine if it
turns out to be a PITA w/ Mercurial that this is where most checkin problems
("fast-forward" in Stephen's terminology) would happen with Subversion.
Skip
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