Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 31 Dec 2012 17:46:22 -0600] rev 18165
histedit: allow operation from non-head if obsolete is enabled
Obsolescence markers can represent this situation just fine. Rewritten
revisions are marked as precursors of the ones creates by
histedit. Unaffected descendants become "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 31 Dec 2012 17:45:52 -0600] rev 18164
rebase: allow non-head rebase-set when obsolete is enabled
Obsolescence markers can represent this situation just fine. Rebased
revisions are marked as precursors of the ones create by
rebase. Unrebased descendants becomes "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 31 Dec 2012 17:44:18 -0600] rev 18163
amend: allow amend of non-head when obsolete is enabled
Obsolescence marker can represent this situation just fine. The old
version is marked as precursor of the new changeset. All its
descendants become "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 21 Dec 2012 22:58:59 +0100] rev 18162
obsolete: factorise troubles detection during push
The use of the two methods introduced earlier allows a factorisation of the
push code preventing push of troubled changeset.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 15:17:54 +0100] rev 18161
obsolete: introduce a troubles method on context
A troubled changeset may be affected by multiple trouble at the same time. This
new method returns a list of all troubles affecting a changes.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 15:06:15 +0100] rev 18160
obsolete: introduce a troubled method on context
Allows to quickly check if a changeset is affected by any troubles.
(troubles are: unstable, bumped and divergent)
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 14:22:24 +0100] rev 18159
tests: fix windows test failures
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 14:13:06 +0100] rev 18158
merge with stable
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 14:10:35 +0100] rev 18157
tests: fix windows test failures
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18156
largefiles: better test coverage of wireproto and the http protocol
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18155
largefiles: cleanup of warnings on errors getting largefiles
Especially the "no default or default-push path set in hgrc" was often very
misleading and didn't give any hint where it actually was looking.
A long error messages is better than several multi-line messages.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18154
largefiles: remove trivial portability wrappers
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18153
largefiles: remove reporemove portability wrapper
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18152
largefiles: remove findoutgoing portability wrapper
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18151
largefiles: use constant for '.hglf/'
Problem: '.hglf' + '/' was computed in some tight loops. There is no need for
that.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18150
largefiles: use plain wjoin instead of the complex pathto
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:57 +0100] rev 18149
largefiles: unindent code
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18148
largefiles: simplify lfdirstate ignore handling - it is only for tracking .hglf
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18147
largefiles: rename 'admin' to more descriptive 'lfstoredir'
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18146
largefiles: simplify lfutil.getstandinmatcher by inlining getmatcher
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18145
largefiles: remove overly complex handling of ignored and unknown files
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:57 +0100] rev 18144
largefiles: introduce basic debugstate --large functionality
Very useful for debugging largefiles "performance" issues.
This is used for testing 03faf12fbee7.
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:57 +0100] rev 18143
util: fold ENOENT check into unlinkpath, controlled by new ignoremissing flag
Refactor a common pattern.
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:45 +0100] rev 18142
merge with stable
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18141
largefiles: don't walk through all ignored files
Problem: 'hg status' with largefiles enabled would walk through all the files
that .hgignore said should be ignored. That made it slow if a lot of files were
.hgignored or the cache was cold.
It seems like there was a reason to this, but other improvements has rendered
this unnecessary.
Solution: .hgignore is now only ignored when that is requested (--ignore).
This is a minimal 'stable' change. There is room for other improvement.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18140
largefiles revert: update lfdirstate with result from first cleanliness check
Largefiles revert do for some reason have two lfdirstates and lfdirstatestatus
invocations in one function. The result from the first lfdirstate check was
however not written back to the lfdirstate, and some files was thus checked
twice.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18139
largefiles status: update lfdirstate with result from cleanliness check
Problem: 'hg status' kept checking largefiles with an unknown state until some
other command wrote the updated dirstate.
Solution: Add missing lfdirstate.write().
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:16:01 +0100] rev 18138
bundlerepo: don't return the peer without bundlerepo from getremotechanges
Problem:
getremotechanges would return the 'other' repo if nothing was incoming and
there thus wasn't any bundle to base the repo on. The 'other' could be a http
peer which only implement the functionality available over the http protocol.
Transplant could thus fail with
TypeError: argument of type 'httppeer' is not iterable
Solution:
Return the local repo instead of the remote peer if there is no reason to place
a bundlerepo on top of the local repo.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 28 Dec 2012 00:02:40 +0100] rev 18137
strip: do not update branchcache during strip (issue3745)
At this moment, the cache is invalid, and will be thrown away.
Later the strip function will call the `localrepo.destroyed` method
that will update the branchmap cache.
Siddharth Agarwal <sid0@fb.com> [Wed, 26 Dec 2012 15:04:07 -0800] rev 18136
copies: do not track backward copies, only renames (issue3739)
The inverse of a rename is a rename, but the inverse of a copy is not a copy.
Presenting it as such -- in particular, stuffing it into the same dict as real
copies -- causes bugs because other code starts believing the inverse copies
are real.
The only test whose output changes is test-mv-cp-st-diff.t. When a backwards
status -C command is run where a copy is involved, the inverse copy (which was
hitherto presented as a real copy) is no longer displayed.
Keeping track of inverse copies is useful in some situations -- composability
of diffs, for example, since adding "a" followed by an inverse copy "b" to "a"
is equivalent to a rename "b" to "a". However, representing them would require
a more complex data structure than the same dict in which real copies are also
stored.
Siddharth Agarwal <sid0@fb.com> [Wed, 26 Dec 2012 15:03:58 -0800] rev 18135
copies: make debug messages more sensible
The -> in debug messages is currently overloaded to mean both source to dest
and dest to source. To fix this, we add explicit labels and make the arrow
direction consistent.
Siddharth Agarwal <sid0@fb.com> [Wed, 26 Dec 2012 14:50:17 -0800] rev 18134
copies: separate moves via directory renames from explicit copies
Currently the "copy" dict contains both explicit copies/moves made by a
context and pending moves that need to happen because the other context moved
the directory the file was in. For explicit copies, the dict stores a
destination to source map, while for pending moves via directory renames, it
stores a source to destination map. The merge code uses this fact in a non-
obvious way to differentiate between these two cases.
We make this explicit by storing these pending moves in a separate dict. The
dict still has a source to destination map, but that is called out in the
docstring.
Kevin Bullock <kbullock@ringworld.org> [Wed, 26 Dec 2012 11:16:18 -0600] rev 18133
merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 24 Dec 2012 02:49:59 +0100] rev 18132
branchmap: move validity logic in the object itself
In several place, We check if a branchcache is still valid regarding the current
state of the repository. This changeset puts this logic in a method of the object
that can be reused when necessary.
A branch map is considered valid whenever it is up to date or a strict subset of
the repository state.
The change will help making branchcache aware of filtered revision.
The change in keyword is expected. the branch cache is actually invalid after
the amend. The previous check did not detected it.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 22 Dec 2012 17:08:15 +0100] rev 18131
branchmap: make update a method
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 24 Dec 2012 02:22:04 +0100] rev 18130
branchmap: make update responsible to update the cache key
The update function have all necessary data to keep the branchcache key
up to date with its value.
This saves assignment to the cache key that each caller of update had to do by
hand.
The strip case is a bit more complicated to handles from inside the function but
I do not expect any impact.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:11:12 +0100] rev 18129
branchmap: factorise changelog access in update
This both improves readability and performance. Access to changelog of filtered
repository currently have a minor overhead.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 16:28:43 +0100] rev 18128
branchmap: make write a method on the branchmap object
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:04:49 +0100] rev 18127
branchmap: simplify write signature
All necessary data (cache value and key) are now stored in the branchcache
object. Any extra parameter is superfluous.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 02:06:26 +0100] rev 18126
branchmap: add the tiprev (cache key) on the branchmap object
The actual cache key used on disk is the (tipnode, tiprev) pair. There is no
reason not to use the revision number for the in memory version.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 01:59:05 +0100] rev 18125
branchmap: add the tipnode (cache key) on the branchcache object
Gathering data and cache key paves the way to a lot of simplification.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 01:44:42 +0100] rev 18124
branchmap: store branchcache in a dedicated object
Value and key of branchcache would benefit from being hold by the same object.
Moreover some logic (update, write, validation) could be move on such object.
The creation of this object is the first step toward this move. The result will
clarify branchcache related code and hide most of the detail in the class
itself. This encapsulation will greatly helps implementation of branchcache for
filtered view of the repo.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Sat, 22 Dec 2012 01:34:23 +0100] rev 18123
branchmap: `stream_in` write remote branchcache to local one
The previous code was writing it to a non existent `branchcache` attribute. We
now write is to the proper `_branchcache` attribute and initialize the
`_branchcachetip` at the same time.
We keep writing it to disk, the previous code had this part right.
Mads Kiilerich <mads@kiilerich.com> [Mon, 24 Dec 2012 13:26:13 +0100] rev 18122
bookmarks: fix head selection for merge with two bookmarked heads
A type mismatch caused the search for the other head to fail. The code is
fragile, and instead it ended up using the 'first' bookmark head, but the
ordering is undefined and it could thus randomly use the wrong bookmarkhead
and fail with:
$ hg up -q -C e@diverged
$ hg merge
abort: merging with a working directory ancestor has no effect
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 14:45:17 +0100] rev 18121
branchmap: extract updatebranchcache from repo
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 14:49:06 +0100] rev 18120
branchmap: extract _updatebranchcache from repo
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 14:47:38 +0100] rev 18119
branchmap: _updatebranchmap does not need to be filtered
The `_updatebranchmap` method on repo does not need to be filtered as all
callers are already handling filtering themself.
The fact it is filtered may had even lead to buggy behaviors, but by chances the method
make very sparse use of the repo object.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 14:46:57 +0100] rev 18118
branchmap: extract read logic from repo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Dec 2012 13:37:37 +0100] rev 18117
branchmap: extract write logic from localrepo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 19 Dec 2012 14:43:33 +0100] rev 18116
branchmap: create a mercurial.branchmap module
This is the foundation stone for an extraction of branches map logic from local
repository class. Most of the branches map logic have very few caller and
therefor does not fit in the current criteria for code held by the localrepo
class. Important change will be made to this code in relation with revision
filtering. So we extract it in a dedicated module before adding additional
complexity.
Follow up commit do the actual code movement.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 12:17:44 +0100] rev 18115
bundlerepo: use _cacheabletip mechanism in bundlerepo
Instead of preventing any cache write we allow writing cache for all content of
the original repo.
The motivation for this change is to drop the custom _writebranchcache of
bundlerepo to help extraction of the branchmap logic out of localrepo.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 20 Dec 2012 13:23:29 +0100] rev 18114
branchmap: merge _branchtags into updatebranchcache
Now that nobody overwrite it, there is no reasons for `_branchtags` to remains
separated from `updatebranchcache`.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 19 Dec 2012 17:39:49 +0100] rev 18113
branchmap: factorise access to changelog in updatebranchcache
This prepares merge of `updatebranchcache` and `_branchtags`.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 20 Dec 2012 11:52:50 +0100] rev 18112
branchmap: simplify _branchtags using a new _cacheabletip method
The current _branchtags method is a remnant of an older, much larger function.
Its only remaining role is to help MQ to alter the version of branchcache we
store on disk. As MQ mutates the repository it ensures persistent cache does not
contain anything it is likely to alter.
This changeset makes explicit the stable vs volatile part of repository and
reduces the MQ specific code to the computation of this limit. The main
_branchtags code now handles this possible limit in all cases.
This will help to extract the branchmap logic from the repository.
The new code of _branchtags is a bit duplicated, but as I expect major
refactoring of this section I'm not keen to setup factorisation function here.
Dirkjan Ochtman <dirkjan@ochtman.nl> [Thu, 20 Dec 2012 21:26:30 +0100] rev 18111
hook: disable demandimport before importing hooks
This solved an obscure bug for me. In upgrading Distribute on the server, a
patch was added to has a try: import a except ImportError thing that's only
supposed to work with Python 3.3. I'm using 2.7. My hook failed with an
ImportError because of this. It seems kind of sensible to turn off
demandimport before importing the hook, since the except ImportError pattern
is used quite a bit in Python code (including in other Distribute code).
Adrian Buehlmann <adrian@cadifra.com> [Thu, 20 Dec 2012 15:18:41 +0100] rev 18110
test-pathencode: accept --seed parameter in hex as well
test-pathencode.py outputs the seed value in hex if it finds a deviation.
This change allows to specify the seed value as a command line
parameter for test-pathencode.py in hex as well.
Angel Ezquerra <angel.ezquerra@gmail.com> [Thu, 13 Dec 2012 23:37:53 +0100] rev 18109
subrepo: append subrepo path to subrepo error messages
This change appends the subrepo path to subrepo errors. That is, when there
is an error performing an operation a subrepo, rather than displaying a message
such as:
pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH!
hint: did you forget to merge? use push -f to force
mercurial will show:
pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH! (in subrepo MYSUBREPO)
hint: did you forget to merge? use push -f to force
The rationale for this change is that the current error messages make it hard
for TortoiseHg (and similar tools) to tell the user which subrepo caused the
push failure.
The "(in subrepo MYSUBREPO)" message has been added to those subrepo methods
were it made sense (by using a decorator). We avoid appending "(in subrepo XXX)"
multiple times when subrepos are nexted by throwing a "SubrepoAbort" exception
after the extra message is appended. The decorator will then "ignore" (i.e. just
re-raise) the exception and never add the message again.
A small drawback of this method is that part of the exception trace is lost when
the exception is catched and re-raised by the annotatesubrepoerror decorator.
Also, because the state() function already printed the subrepo path when it
threw an error, that error has been changed to avoid duplicating the subrepo
path in the error message.
Note that I have also updated several subrepo related tests to reflect these
changes.
Kevin Bullock <kbullock@ringworld.org> [Thu, 20 Dec 2012 13:49:31 -0600] rev 18108
tests: fix some slash-based Windows failures
Bryan O'Sullivan <bryano@fb.com> [Thu, 20 Dec 2012 11:40:04 -0800] rev 18107
inotify: on Python < 2.6, socket.error lacks errno
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 18 Dec 2012 01:51:08 +0100] rev 18106
hidden: invalidate hiddenrevs when needed
The `hiddenrevs` cache is volatile too (It use content from `obscache`). When
unsure it is invalidated when necessary. In a near future, the cache will
probably be moved to `revsfiltercache`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 18 Dec 2012 02:04:37 +0100] rev 18105
cache: group obscache and revsfiltercache invalidation in a single function
Both caches are very volatile and needs invalidation on the same kind of event.
revsfiltercache actually depends on the content of revsfiltercache.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Dec 2012 17:27:12 +0100] rev 18104
clfilter: use filtering in `visibleheads`
This is the second real use of changelog filtering. The change is very small to
allow testing the new filter with a setup close to the original one.
We replace custom post processing on `heads`function by call to the standard
code pass on a filtering repo.
In later coming will have wider usage of filtering that will make the dedicated
function useless.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 17:42:34 +0100] rev 18103
clfilter: use filtering in `visiblebranchmap`
Here is the first real use of changelog filtering. The change is very small to
allow testing the new filter with a setup close to the original one.
We replace custom post processing on branchmap function by call to the
standard code pass on a filtering repo.
In later coming will have wider usage of filtering that will make the dedicated
function useless.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 17 Dec 2012 17:12:02 +0100] rev 18102
clfilter: introduce a "unserver" filtering mode
This mode is for repository used as a server. It filter secret and hidden
changeset out.
It is put to use in later changeset.