Wed, 27 Aug 2014 23:10:06 +0900 import: show the warning message for failure of merging stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 27 Aug 2014 23:10:06 +0900] rev 22303
import: show the warning message for failure of merging Before this patch, no message is shown for failure of merging at "hg import". In such case, merging patch is imported as a normal revision silently, and it may confuse users. For simplicity, this patch recommends just using "--exact", even though importing the merging patch itself is possible without it if: - the hash of the 1st parent in the patch is equal to one of the patch imported just before (or the parent of the working directory, for the 1st patch of the series), and - the hash of the 2nd parent in the patch is known in the local repository
Wed, 27 Aug 2014 15:30:09 +0200 graft: fix collision detection with origin revisions that are missing stable
Mads Kiilerich <madski@unity3d.com> [Wed, 27 Aug 2014 15:30:09 +0200] rev 22302
graft: fix collision detection with origin revisions that are missing When grafting something with a matching origin, it would normally be skipped: skipping already grafted revision 123 (23 also has origin 12) But after stripping a graft origin, graft could fail with a reference to the origin that no longer exists: abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'! Instead, detect that the origin is unknown and skip it anyway, like: skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
Sat, 23 Aug 2014 17:03:08 -0500 log: use correct phase info for parent field (issue4347) stable
Sean Farley <sean.michael.farley@gmail.com> [Sat, 23 Aug 2014 17:03:08 -0500] rev 22301
log: use correct phase info for parent field (issue4347) Previously, there was a copy / paste error with using the current changeset's phase information. We now look up the parent context explicitly. The line was too long so it is stored into a variable first.
Tue, 26 Aug 2014 22:03:32 +0200 convert: introduce --full for converting all files
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Aug 2014 22:03:32 +0200] rev 22300
convert: introduce --full for converting all files Convert will normally only process files that were changed in a source revision, apply the filemap, and record it has a change in the target repository. (If it ends up not really changing anything, nothing changes.) That means that _if_ the filemap is changed before continuing an incremental convert, the change will only kick in when the files it affects are modified in a source revision and thus processed. With --full, convert will make a full conversion every time and process all files in the source repo and remove target repo files that shouldn't be there. Filemap changes will thus kick in on the first converted revision, no matter what is changed. This flag should in most cases not make any difference but will make convert significantly slower. Other names has been considered for this feature, such as "resync", "sync", "checkunmodified", "all" or "allfiles", but I found that they were less obvious and required more explanation than "full" and were harder to describe consistently.
Tue, 26 Aug 2014 22:03:32 +0200 convert: refactor hg getchanges and caching
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Aug 2014 22:03:32 +0200] rev 22299
convert: refactor hg getchanges and caching
Tue, 26 Aug 2014 22:03:32 +0200 convert: refactor subversion getchanges and caching
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Aug 2014 22:03:32 +0200] rev 22298
convert: refactor subversion getchanges and caching
Tue, 26 Aug 2014 22:03:32 +0200 convert: remove incorrect and unused handling of removed svn directories
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Aug 2014 22:03:32 +0200] rev 22297
convert: remove incorrect and unused handling of removed svn directories Since it was introduced in f0c58fd4b798, tidy_dirs has been comparing the result of os.listdir with a string - which never can be true. Convert apparently works anyway and there is no test coverage of it. It also seems like it could make a bigger difference on older svn versions but is less relevant with more recent versions. Instead of trying to fix the code, we take the low risk option and remove it.
Tue, 26 Aug 2014 22:03:32 +0200 convert: use None value for missing files instead of overloading IOError
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Aug 2014 22:03:32 +0200] rev 22296
convert: use None value for missing files instead of overloading IOError The internal API used IOError to indicate that a file should be marked as removed. There is some correlation between IOError (especially with ENOENT) and files that should be removed, but using IOErrors to represent file removal internally required some hacks. Instead, use the value None to indicate that the file not is present. Before, spurious IO errors could cause commits that silently removed files. They will now be reported like all other IO errors so the root cause can be fixed.
Wed, 27 Aug 2014 12:30:28 +0200 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 27 Aug 2014 12:30:28 +0200] rev 22295
merge with stable
Mon, 25 Aug 2014 03:27:51 +0200 convert: p4: ignore purged files with p4d 2012.2 and later
Mads Kiilerich <madski@unity3d.com> [Mon, 25 Aug 2014 03:27:51 +0200] rev 22294
convert: p4: ignore purged files with p4d 2012.2 and later Perforce has the concept of "+Sn" files where only the last revisions of the file is stored. In p4d 2012.1 old purged revisions were not included in the "manifest". With 2012.2 they started being included and convert's getfile failed to recognize the "purged" flag and saw it as an empty file. That made test-convert-p4-filetypes.t fail. There is no point in storing an empty file as placeholder for a purged file so we restore the old behaviour by checking the flag and letting getfile consider purged files deleted. (It is questionable whether it makes sense to convert not-yet-purged +S files to mercurial ... but that is another question.)
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip