FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21049
hg: make "_outgoing()" return empty list instead of "None"
This patch makes "_outgoing()" return empty list instead of "None", if
there are no outgoing changesets, because:
- returning "None" requires callers to examine whether returned
value is "None" or not explicitly, if callers want to execute loop
on returned value, but
- there are no explicit needs to return "None"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21048
largefiles: use "summaryremotehooks" to avoid redundant outgoing check
Before this patch, "hg summary --remote --large" invokes
"findcommonoutgoing()" not only in "commands.summary()" but also in
"overrides.overridesummary()" (via "getoutgoinglfiles()"). The latter
is redundant.
This patch uses "summaryremotehooks" to avoid redundant outgoing check.
Newly introduced function "overrides.summaryremotehook()" is
registered into "summaryremotehooks" to get the result of outgoing
check in "commands.summary()".
It invokes "lfutil.getlfilestoupload()" directly with the result of
outgoing check to avoid redundant outgoing check in
"getoutgoinglfiles()".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21047
summary: introduce "summaryremotehooks" to avoid redundant incoming/outgoing check
This patch introduces "summaryremotehooks" to avoid redundant
incoming/outgoing check for "hg summary" in other than
"commands.summary".
Only if "--remote" is not specified for "hg summary", hooks registered
in "summaryremotehooks" are invoked with "None" as "changes" argument
at first, and they should return tuple of two booleans meaning
"whether incomings are needed" and "whether outgoings are needed".
If no hooks return tuple containing "True", "hg summary" does nothing
any more, because incoming/outgoing check is not needed.
Otherwise, hooks are invoked again: at this time, "changes" argument
refers the result of incoming/outgoing check.
This patch also prevents RepoError from being raised if "--remote" is
not specified for "hg summary", because of backward compatibility for
"hg summary --large" without "--remote".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21046
util: enable "hooks" to return list of the values returned from each hooks
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21045
summary: separate checking incoming/outgoing and showing remote summary
This patch separates checking incoming/outgoing and showing remote
summary, as a preparation for refactoring in succeeding patches,
because:
- checking incoming/outgoing may be needed, even if "--remote" is
not specified for "hg summary"
- checking incoming/outgoing may not be needed simultaneously
"hg summary --large" without "--remote" is typical case for these.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21044
largefiles: reuse "findcommonoutgoing()" result at "hg push"
Before this patch, "hg push" invokes "findcommonoutgoing()" not only
in "exchange.push()" but also in "lfilesrepo.push()", when largefiles
is enabled. The latter is redundant.
This patch registers own "prepushoutgoinghook" function into
"prepushoutgoinghooks" of "localrepository" to reuse
"findcommonoutgoing()" result.
"prepushoutgoinghook" omits "changelog.nodesbetween()" invocation,
because "findcommonoutgoing()" invocation in "exchange.push()" takes
"onlyheads" argument and it considers "nodesbetween()".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21043
localrepo: introduce "prepushoutgoinghooks" to extend outgoing check easily
This patch introduces "prepushoutgoinghooks" to extend outgoing check
before pushing changesets to remote easily.
This chooses the function returning "util.hooks" instead of the one to
be overridden.
The latter may cause problems silently, if one of overriders forgets
(or fails) to execute a kind of "super(xxx, self).overridden(...)". In
the other hand, the former can ensure that all registered functions
are invoked, unless one of them raises an exception.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 16 Apr 2014 00:37:24 +0900] rev 21042
largefiles: centralize the logic to get outgoing largefiles
Before this patch, "overrides.getoutgoinglfiles()" (called by
"overrideoutgoing()" and "overridesummary()") and "lfilesrepo.push()"
implement similar logic to get outgoing largefiles separately.
This patch centralizes the logic to get outgoing largefiles in
"lfutil.getlfilestoupload()".
"lfutil.getlfilestoupload()" takes "addfunc" argument, because each
callers need different information (and it is useful for enhancement
in the future).
- "overrides.getoutgoinglfiles()" needs only filenames
- "lfilesrepo.push()" needs only hashes of largefiles
Matt Harbison <matt_harbison@yahoo.com> [Fri, 14 Mar 2014 21:32:05 -0400] rev 21041
cat: support cat with explicit paths in subrepos
The cat command with an explicit path into a subrepo is now handled by invoking
cat on the file, from that subrepo. The previous behavior was to complain that
the file didn't exist in the revision (of the top most repo). Now when the file
is actually missing, the revision of the subrepo is named instead (though it is
probably desirable to continue naming the top level repo).
The documented output formatters %d and %p reflect the path from the top level
repo, since the purpose of this is to give the illusion of a unified repository.
Support for the undocumented (for cat) formatters %H, %R, %h, %m and %r was
added long ago (I tested back as far as 0.5), but unfortunately these will
reflect the subrepo node instead of the parent context.
The previous implementation was a bit loose with the return value, i.e. it would
return 0 if _any_ file requested was cat'd successfully. This maintains that
behavior.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 13 Mar 2014 23:45:18 -0400] rev 21040
cat: move most of the implementation into cmdutils.cat()
This will allow access to the reusable parts from subrepos, similar to add(),
forget(), etc.