Sean Farley <sean.michael.farley@gmail.com> [Tue, 22 Apr 2014 13:14:51 -0500] rev 21397
context: add private _dirstatestatus method
This patch is a step forward in getting rid of needing to check 'parentworking'
throughout the status method. Eventually, we will use the power of inheritance
to do the correct thing when comparing the working directory with its parent.
This method is mostly a copy from localrepo.status. The custom status method of
workingctx will eventually be absorbed by the refactoring of localrepo.status
to context.status but unfortunately we can't do it in one step.
Sean Farley <sean.michael.farley@gmail.com> [Tue, 11 Mar 2014 18:28:09 -0500] rev 21396
committablectx: move status to workingctx
This method was accidentally placed into the committablectx class. It contains
logic for querying the dirstate so we move it to the correct class.
Sean Farley <sean.michael.farley@gmail.com> [Tue, 11 Mar 2014 18:10:00 -0500] rev 21395
localrepo: factor out parentworking logic for comparing files
We will temporarily call a private method of the context class while we are in
the process of removing the need of having localrepo.status.
Sean Farley <sean.michael.farley@gmail.com> [Tue, 11 Mar 2014 17:44:09 -0500] rev 21394
localrepo: improve dirstate.normal lookup by cacheing the function
Sean Farley <sean.michael.farley@gmail.com> [Fri, 07 Mar 2014 13:32:37 -0800] rev 21393
localrepo: move symlink logic to workingctx
Mads Kiilerich <madski@unity3d.com> [Fri, 09 May 2014 12:01:56 +0200] rev 21392
merge: separate worker functions for batch remove and batch get
The old code had one function that could do 2 different things. First,
is was called a bunch of times to do one thing. Next, it was called a
bunch of times to do the other thing. That gave unnecessary complexity
and a dispatch overhead. Having separate functions is "obviously" better
than having a function that can do two things, depending on its parameters.
It also prepares the code for the next refactorings.
Mads Kiilerich <madski@unity3d.com> [Tue, 22 Apr 2014 02:10:25 +0200] rev 21391
merge: change debug logging - test output changes but no real changes
Preparing for action list split-up, making sure the final change don't have any
test changes.
The patch moves debug statements around without really changing anything.
Arguably, it temporarily makes the code worse. The only justification is that
it makes it easier to review the test changes ... and in the end the big change
will not change test output at all.
The changes to test output are due to changes in the ordering of debug output.
That is mainly because we now do the debug logging for files when we actually
process them. Files are also processed in a slightly different but still
correct order. It is now primarily ordered by action type, secondarily by
filename.
The patch introduces some redundancy. Some of it will be removed again, some of
it will in the end help code readability and efficiency. It is possible that we
later on could introduce a "process this action list and do some logging and
progress reporting and apply this function".
The "preserving X for resolve" debug statements will only have single space
indentation. It will no longer have a leading single space indented "f: msg ->
m" message. Having this message double indented would thus no longer make
sense.
The bid actions will temporarily be sorted using a custom sort key that happens
to match the sort order the simplified code will have in the end.
Mads Kiilerich <madski@unity3d.com> [Thu, 15 May 2014 02:14:59 +0200] rev 21390
merge: move constant assignments a bit and use them more
Mads Kiilerich <madski@unity3d.com> [Fri, 02 May 2014 01:09:14 +0200] rev 21389
merge: change priority / ordering of merge actions
The ordering of actions matters. Normal file system semantics is that files
have to be removed before a directory with the same name can be created.
Before the first ordering key was to have 'r' and 'f' actions come first,
secondary key was the filename.
Because of future refactorings we want to consistently have all action types
(with a sensible priority) as separate first keys. Grouped by action type, we
sort by filename.
Not processing in strict filename order could give worse performance,
especially on spinning disks. That is however primarily an issue in the cases
where "all" actions are of the same kind and will be grouped together anyway.
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 17 May 2014 00:47:42 -0700] rev 21388
run-tests: fix --interactive option
``TTest._testpath`` never existed. This must be the remain of some contributors
side refactoring.