Sun, 04 Jan 2015 15:26:26 -0500 largefiles: properly sync lfdirstate after removing largefiles stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 04 Jan 2015 15:26:26 -0500] rev 23721
largefiles: properly sync lfdirstate after removing largefiles The more aggressive synchronization of lfdirstate that was backed out in 1265a3a71d75 masked the problem where lfdirstate would hold an 'R' for a largefile that was added and then removed without a commit between. We could just conditionally call lfdirstate.drop() or lfdirstate.remove() here, but this also properly updates lfdirstate if the standin doesn't exist for the file somehow (i.e. call drop instead of remove). Without this change, the precommit status in the commit command immediately after the test change lists the removed (and never committed) largefile as 'R'. It can also lead to situations where the status command reports the same, long after the commit [1]. [1] http://www.selenic.com/pipermail/mercurial-devel/2015-January/065153.html
Mon, 29 Dec 2014 18:35:23 -0800 linkrev-filelog: handle filtered linkrev with no visible children (issue4307)
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 29 Dec 2014 18:35:23 -0800] rev 23720
linkrev-filelog: handle filtered linkrev with no visible children (issue4307) If the file revision with a filtered linkrev does not have any (unfiltered) children, we cannot use it to bound the search for another introduction. Instead, we have to look at the file revision used by each head changeset. If one of them uses this file revision, we know there is another occurrence and we have a starting point. See inline comments for details. Adding some kind of permanent reference of all the introductions of a file revision instead of just the first one would be much better. But this is more difficult. I hope to take that into account in the next repository format.
Mon, 29 Dec 2014 17:23:16 -0800 linkrev: work around linkrev to filtered entry in 'filelog' revset
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 29 Dec 2014 17:23:16 -0800] rev 23719
linkrev: work around linkrev to filtered entry in 'filelog' revset This revset is used by 'hg log FILENAME'. This prevent bugs when used on a repository with hidden revisions. Instead of just discarding file revisions whose linkrevs point to filtered revisions, we put them aside and post-process them trying to find a non-filtered introduction. See inline documentation for details about how it works. This only fixes some of the problems. Once again, more will be needed when we can cannot rely on child revisions of a file to find linkrev-shadowned revisions. A test is added for 'hg log' catching such cases.
Sun, 21 Dec 2014 13:06:24 -0800 namespaces: update documentation and code indentation
Sean Farley <sean.michael.farley@gmail.com> [Sun, 21 Dec 2014 13:06:24 -0800] rev 23718
namespaces: update documentation and code indentation The previous patch changed just the functionality, while this patch focuses on the documentation and indentation to keep review simple.
Fri, 19 Dec 2014 17:27:20 -0800 namespaces: use namespace object instead of dictionary
Sean Farley <sean.michael.farley@gmail.com> [Fri, 19 Dec 2014 17:27:20 -0800] rev 23717
namespaces: use namespace object instead of dictionary This isn't as bad as the diff seems, it only looks like scary. In this patch, we use the 'namespace' object instead of accessing keys in a dictionary. This required the 'templatename' and 'names' method to change their implementation. Later, we will remove these functions entirely due to a better api.
Fri, 19 Dec 2014 17:17:17 -0800 namespaces: copy implementation to new namespace object
Sean Farley <sean.michael.farley@gmail.com> [Fri, 19 Dec 2014 17:17:17 -0800] rev 23716
namespaces: copy implementation to new namespace object
Fri, 19 Dec 2014 17:00:28 -0800 namespaces: add a namespace object
Sean Farley <sean.michael.farley@gmail.com> [Fri, 19 Dec 2014 17:00:28 -0800] rev 23715
namespaces: add a namespace object Currently, we use a dictionary object to store the namespace properties. This is python so let's use an object. This will allow us to be more flexible in our method signatures in the future.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip