- Oct 08, 2015
-
-
Siddharth Agarwal authored
This makes the overall filemerge function easier to follow, and makes upcoming work simpler.
-
Siddharth Agarwal authored
Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
-
Siddharth Agarwal authored
Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
-
Siddharth Agarwal authored
Cleanup from an earlier patch to make premerge be directly called from the main filemerge function.
-
- Oct 05, 2015
-
-
Pierre-Yves David authored
The revset is not used anywhere anymore. We delete the function until we use (and therefore test it again).
-
- Sep 29, 2015
-
-
Pierre-Yves David authored
There is no value in using the revset instead of the extracted function.
-
- Oct 05, 2015
-
-
Pierre-Yves David authored
We ultimately want this to be accessible through a revset, but there is too much complexity here for that to work. Especially we'll have to return more than just the destination to control the behavior (eg: bookmarks to activate, etc). To prevent cycle, a new module is created, it will receive other destination/behavior function in the future.
-
- Oct 08, 2015
-
-
Gregory Szorc authored
This is a backout of d29859cfcfc2. The stdlib implementation of multiprocessing.cpu_count() attempts to invoke a process on BSD and Darwin platforms (at least on 2.7). Under certain conditions (such as cwd being removed) this could raise. Our old code was silently catching the exception. The old code was more robust, so restore it.
-
Siddharth Agarwal authored
The merge code currently does (in pseudocode): for f in tomerge: premerge f merge f We'd like to change this to look more like: for f in tomerge: premerge f for f in tomerge: merge f This makes sure as many files are resolved as possible before prompting for the others. This restructuring is also necessary for custom merge drivers. This function separates out the premerge step from the merge step. In future patches we'll actually turn these into separate steps in the merge driver. The 'if r:' occurrences will be cleaned up in subsequent patches.
-
- Oct 05, 2015
-
-
Durham Goode authored
In the external pushrebase extension, it is valuable to be able to do some work without taking the lock (like running expensive hooks). This enables significantly higher commit throughput. This patch adds an option to lazily acquire the lock. It means that all bundle2 part handlers that require writing to the repo must first call op.gettransction(), when in this mode.
-
- Oct 06, 2015
-
-
Durham Goode authored
A future patch will allow the bundle2 lock be taken lazily. We need to introduce transaction-gets to each handler that needs the lock. The tests caught these issues when I added lazy locking.
-
- Oct 08, 2015
-
-
Matt Mackall authored
-
- Oct 02, 2015
-
-
Pierre-Yves David authored
patchbomb relies on the 'hg bundle' command to generate an attached bundle using --bundle. However, while 'hg bundle' has a --type option, patchbomb did not. This is becoming very relevant since we are about to issue bundle2 for general-delta repository. This was tracked as issue4863
-
- Oct 07, 2015
-
-
Pierre-Yves David authored
As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook point to do extra work after the import have been committed.
-
- Oct 06, 2015
-
-
Pierre-Yves David authored
As we have a way for extension to add more header, we need a way for them to actually process them. We add a basic hook points to alter the changeset (especially extra) before we commit. There would be more to do for a full featured hooking, but this currently fit my needs.
-
Pierre-Yves David authored
Parsing 'nodeid' is very simple and a good first test.
-
Pierre-Yves David authored
Parsing 'branch' is very simple and a good first test.
-
- Oct 07, 2015
-
-
Pierre-Yves David authored
Parsing 'date' is very simple and a good first test.
-
Pierre-Yves David authored
We need a way for extension to extend the header we can parse. We start with a very simple mechanism that will be used in the next changeset.
-
- Oct 06, 2015
-
-
Pierre-Yves David authored
It is not heavily used enough to justify being something other than a dictionary entry.
-
Pierre-Yves David authored
The differences between both returns are now very thin, we factor out that part.
-
- Oct 07, 2015
-
-
Pierre-Yves David authored
The is one setter and no consumer, we can move it there directly.
-
- Oct 06, 2015
-
-
Pierre-Yves David authored
There is one setter and no consumer, we can move it there directly.
-
Pierre-Yves David authored
This is used in both case, we can assign it once.
-
Pierre-Yves David authored
There is one setter and no consumer, we can move it there directly.
-
Pierre-Yves David authored
The temporary variables are not adding anything.
-
Pierre-Yves David authored
This return is shared between the two cases. We can move it earlier.
-
Pierre-Yves David authored
We move to the more standard style of: value = default if special: value = other This is more consistent and compact.
-
Pierre-Yves David authored
The final goal here is to be able to parse, return and process arbitrary data from patch. This mirror the recently added ability to add arbitrary data to patch headers. The first step is to return something more flexible, so we return a dict without changing any other logic.
-
Pierre-Yves David authored
This config allows to specify a public location where your changeset can be found. It then include a dedicated patch header show a command to be used to retrieve the change. See the test for example. This is flagged as experimental because this feature is not safe until we have more logic to test that: - changeset actually exists on destination - changeset is draft on destination. As all this is experimental, bike shedding can happily happens before we remove the experimental flag.
-
Pierre-Yves David authored
Extensions currently have no easy way to add data to exported patch. This is now fixed using a generic mechanism in the same fashion used by bundle2. Tests are coming in the next changeset with its first user.
-
- Oct 05, 2015
-
-
Pierre-Yves David authored
Incoming was using bundle1 in all cases, as bundle1 is restricted to changegroup1 and does not support general delta, this can lead to significant CPU overhead if the server is using general delta storage. We now properly request and store a bundle2 to disk. If the server include any output or error in the bundle, they will be stored on disk and replayed when the bundle is read. As 'hg incoming' is going to read the bundle right away, we call that 'good' enough and go back to the bigger plan of having general delta on by default. This was tracked as 4864
-
Pierre-Yves David authored
We are about to add a new condition. Code is indented in a separated patch for readability.
-
- Oct 08, 2015
-
-
Pierre-Yves David authored
There is use case for directly forward and bundle2 stream from the peer to a file (eg: 'hg incoming --bundle'), However ssh peers have no way to know the 'getbundle' is over except for actually interpreting the bundle. So we need to have the unbundle do the interpreting and forward job. The function is marked as private to highlight that this is terrible and that we are sorry.
-
- Oct 05, 2015
-
-
Pierre-Yves David authored
We want to introduce a simple way to forward the content of a bundle2 stream. For this purpose, we will need to both yield the parameters block and process it (to apply any behavior change it might indicate).
-
Pierre-Yves David authored
The current writebundle function do two things: - taking a changegroup-packer instance and storing it into a valid bundle with proper header. - creating a temporary or requested file to store that bundle We would like to make it easier to forward bundle stream directly from a remote peer to a file, so we split the two logic to be able to skip the one about building a valid bundle (the remote is already sending one).
-
Pierre-Yves David authored
We were reading the wrong key...
-
- Oct 07, 2015
-
-
Yuya Nishihara authored
This is what branch() and tag() do.
-
Yuya Nishihara authored
If "literal:" is specified, it must not be a revset expression. It should error out with a better message.
-
Gijs Kruitbosch authored
When users configure the default foreground or background color to non-default (black on white) values, several hgweb styles lack contrast for headers and table row items. This patch fixes that by ensuring that where either foreground or background colors are specified, both are specified.
-