Sat, 03 Jan 2015 11:11:46 +0000 keyword: use vfs.reljoin and util.unlinkpath to remove kwdemo
Christian Ebert <blacktrash@gmx.net> [Sat, 03 Jan 2015 11:11:46 +0000] rev 23722
keyword: use vfs.reljoin and util.unlinkpath to remove kwdemo
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip