The `svn commit` command does not detect changed files unless
their mtime has changed. A quick succession of, for instance,
`svn co ...; echo x >> y; svn ci` can thus lead to the change to y
being ignored.
Edited by pmezard to write in binary mode.
- use changelog.count() as a pseudo revision number
- abort early in copies if revs are the same
- eliminate working dir hacks in copies
- yield results as they're found
Backing out a changeset that is before a named branch branchpoint was
making the reverse changeset the tip of the old branch, which is wrong
and very confusing. So instead, we put it on the current named branch.
With huge history (like kdelibs), the process termination suddenly consumes a
lot of memory (from 700M to 1.3G+). Since the job is done, clean termination is
not required, just exit.
This fixes passing back fail messages mistaken for skip messages when
running with parallel jobs because run_children() only expects one message per
fail.
Up to changeset 6713db859c82, HTTP headers were expected to be embedded
in the "headers" template. Since that changeset, the content-type is
supposed to be defined as the "mimetype" template in the map file.
This changeset makes sure the old templates still work.
- complain about attempts to merge with ancestor
- when updating, differentiate between
- crossing named branches with no local changes (jump)
- crossing named branches with local changes (complain)
- nonlinear update on the same named branch, no changes (complain some more)
- nonlinear update on the same named branch, changes (different complaining)
Somebody may change the dirstate after we've determined the parents of
the working dir and run repo.status, but before we called wlock().
This should also fix issue997, where backout would change a file without
changing its size and then call repo.commit without passing the list of
files. If this happened in less than one second, we wouldn't detect any
file changes - the in-memory dirstate still has the cached stat data for
that file. Grabbing the wlock early causes the dirstate to be
invalidated and we end up reading the dirstate file again, which has
that file marked for lookup (size == -1).
A better fix would be for backout to give repo.commit the exact list of
files, but that'll require some changes to the revert operation.
A significant user-visible change is that the precommit hook is always
run with both locks grabbed - previously, hg commit would run it before
grabbing any locks, but hg import would run it after grabbing locks.
In an extreme case (merging two revisions with very low revision numbers)
this could be slower than the previous code, but it should be much faster
in the usual cases (parents are near the tip). It also avoids some races
in some uninteresting cases (e.g. two concurrent hg commits).
