- Apr 30, 2012
-
-
Patrick Mézard authored
Messing with the dirstate before the intermediate commit seems error prone. Instead, commit and recompute the copies with copies.pathcopies(), then use that with commitctx(). Since copies.pathcopies() does not support file replacement very well, the whole .renamed() condition in samefile() is removed and the "file replacement caused by differing copy source" effect is discarded. Test shamelessly stolen from Idan Kamara <idankk86@gmail.com>
-
Patrick Mézard authored
The weirdness is --amend let you replace one file with another with same data and flags if the new file copy record differ from the one in the parent revision. In theory, there is no problem with this kind of thing, subversion supports it, but here we see log and status disagree. The reason is log reads the copy record from the filelog, while status calls copies.pathcopies() which eventually invokes some expensiveness argument to discard this case (copies.py, _forwardcopies(), line 132). Since the next patch will side with pathcopies(), I prefer to call this behaviour a bug.
-
- Apr 29, 2012
-
-
Patrick Mézard authored
The fix introduced in eab9119c5dee was only partially successful. It is correct to turn dirstate 'm' merge records into normal/dirty ones but copy records are lost in the process. To adjust them as well, we need to look in the first parent manifest to know which files were added and preserve only related records. But the dirstate does not have access to changesets, the logic has to moved at another level, in localrepo.
-
Patrick Mézard authored
- --source and revset - --base and revset - --rev and revset - --rev and --source combination - --rev and --base combination
-
- Apr 30, 2012
-
-
Martin Geisler authored
Brifly explain why rewriting subrepository paths can be necessary. Explain that relative subrepository paths are made absolute before rewrite rules are applied.
-
Martin Geisler authored
I sometimes look at a piece of software and if the man page says "Copyright 2004", then I'm inclined to think that the project is stale or that the authors are lazy. Neither is good publicity for us :-)
-
Martin Geisler authored
-
- Apr 28, 2012
-
-
Matt Mackall authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
Katsunori FUJIWARA authored
-
Patrick Mézard authored
The original issue was something like: $ hg init repo $ cd repo $ mkdir D $ echo a > D/a $ hg ci -Am adda adding D/a $ mv D temp $ mv temp d $ echo b > d/b $ hg add d/b adding D/b $ hg ci -m addb $ hg mv d/b d/c moving D/b to d/c $ hg st A d/c R D/b Here we expected: A D/c R D/b the logic being we try to preserve case of path components already known in the dirstate. This is fixed by the current patch. Note the following stories are not still not supported: Changing directory case $ hg mv D d moving D/a to D/D/a moving D/b to D/D/b $ hg st A D/D/a A D/D/b R D/a R D/b or: $ hg mv D/* d D/a: not overwriting - file exists D/b: not overwriting - file exists And if they were, there are probably similar issues with diffing/patching.
-
kiilerix authored
Don't depend on $environmentvariableexpansion and 'quote' handling in system()
-
- Apr 27, 2012
- Apr 28, 2012
-
-
Patrick Mézard authored
Here is a script illustrating the previous behaviour: The merge brings a new file 'b' from remote $ hg merge 1 --debug searching for copies back to rev 1 unmatched files in other: b resolving manifests overwrite: False, partial: False ancestor: 07f494440405, local: 540395c44225+, remote: 102a90ea7b4a b: remote created -> g updating: b 1/1 files (100.00%) getting b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) Delete but do not remove b $ rm b $ hg st ! b The commit succeeds $ hg commit -m merge $ hg parents --template "{rev} {desc|firstline} files: {files}\n" 3 merge files: $ hg st ! b b changes were ignored, but even b existence was ignored $ hg manifest a This happens because localrepo.commitctx() checks the input ctx.files(), which is empty for workingctx.files() only returns added, modified or removed entries, and bypass files/manifest updates completely. So the committed revision manifest is the same as its first parent one, not containing the 'b' file. This patch forces the commit to abort in presence of a merge and missing files. test-merge4.t is modified accordingly as it was introduced to check hg was not just terminating with a traceback (5e9e8b8d2629).
-
- Apr 24, 2012
-
-
Pierre-Yves David authored
Discovery now use an overlay above branchmap to prune invisible "secret" changeset from branchmap. To minimise impact on the code during the code freeze, this is achieve by recomputing non-secret heads on the fly when any secret changeset exists. This is a computation heavy approach similar to the one used for visible heads. But few sever should contains secret changeset anyway. See comment in code for more robust approach. On local repo the wrapper is applied explicitly while the wire-protocol take care of wrapping branchmap call in a transparent way. This could be unified by the Peter Arrenbrecht and Sune Foldager proposal of a `peer` object. An inappropriate `(+i heads)` may still appear when pushing new changes on a repository with secret changeset. (see Issue3394 for details)
-
- Apr 27, 2012
-
-
Matt Mackall authored
This fixes the regression, but still leaves the long-standing issue that merge doesn't cope with trying to merge files and directories.
-
Matt Mackall authored
This regresses performance of 'hg branches', presumably because it's visiting the revlog in the wrong order. This suggests we either need to fix the branch code or add some read-behind to mitigate the effect.
-
- Apr 26, 2012
-
-
Pierre-Yves David authored
The `repo` object here is *always* local. Using `repo.heads()` ensure we will reject push if any secret changeset exists. During discovery, `visibleheads` were sent to the peer. So we can only expect it to send us `visibleheads` back. If any secret changeset exists:: visibleheads != repo.heads() This fix server side part of issue 3303 when pushing over the wire.
-
- Apr 25, 2012
-
-
Patrick Mézard authored
The previous code was rebasing an applied series like: patch1 +guarded patch2 patch3 +guarded patch4 patch5 +guarded into: patch2 patch4 patch1 +guarded patch3 +guarded patch5 +guarded Reported by Lars Westerhoff <lars.westerhoff@newtec.eu> Also rename mq.series_dirty into mq.seriesdirty, missed by 599a72895c0d, and without effect since mq.qimport() was setting it already.
-
- Apr 26, 2012
-
-
Patrick Mézard authored
From: abort: failed to commit svn changes to: abort: cannot commit missing svn entries
-
Patrick Mézard authored
Previous code was printing a traceback because it expected some error output from svn. But sometimes our definition of "changed" differs with the subversion one. For instance, subversion ignores missing files when committing. And when there are only missing files, svn commit will be a successful no-op with no output. Still, we should stick to our definition including missing files in changes as doing otherwise could cause surprising behaviour for the user.
-
Katsunori FUJIWARA authored
current description of 'matching()' revset predicate can't be formatted well on "hg help revset" output. each descriptions for revset predicates (or something like them) are split-ed into lines, and spaces on left side of them are stripped before minirst processing. so, bullet list can't be nested. this patch just flattens description of 'matching()' predicate to be formatted well.
-
- Apr 27, 2012
-
-
Patrick Mézard authored
-
Patrick Mézard authored
The test was randomly failing with: --- /tests/test-subrepo-svn.t +++ /test-subrepo-svn.t.err @@ -273,10 +273,10 @@ 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd t/s $ svn status - ? * a (glob) - X * externals (glob) - ? * f1 (glob) - ? * f2 (glob) + ? f1 + ? f2 + ? a + X externals Performing status on external item at 'externals'* (glob)
-
Patrick Mézard authored
This test was failing randomly with: --- /tests/test-convert-svn-source.t +++ /tests/test-convert-svn-source.t.err @@ -35,8 +35,8 @@ $ svnurl="file://$svnpath/svn-repo/proj%20B" $ svn import -m "init projB" projB "$svnurl" | fixpath + Adding projB/tags Adding projB/mytrunk - Adding projB/tags Committed revision 1.
-
- Apr 26, 2012
-
-
Patrick Mézard authored
The only place where an trailing CR could be meaningful is in the "diff --git" line as part of a filename, and existing code already rule out this possibility. Extend the CR/LF filtering to the whole binary hunk.
-
Patrick Mézard authored
$ hg import --no-commit ../mercurial_1915035238540490516.patch applying ../mercurial_1915035238540490516.patch abort: could not extract binary data Becomes: abort: could not extract "binary2" binary data
-
- Apr 21, 2012
-
-
Patrick Mézard authored
Before, import was terminating with a traceback. Now it says: $ hg import --no-commit ../bad.patch applying ../bad.patch abort: could not decode binary patch: bad base85 character at position 66
-
- Apr 26, 2012
-
-
Patrick Mézard authored
The fast path was triggered if the argument was not like "type:value", with type a known pattern type. This is wrong for several reasons: - path:value is valid for the fast path - '*' is interpreted as a glob by default and is not valid for fast path Fast path detection is now done after the pattern is parsed, and the normalized path is extracted for direct comparison. All this seems a bit complicated, it is tempting to drop the fast path completely. Also, the hasfile() revset does something similar (only check .files()), without a fast path. If the fast path is really that efficient maybe it should be used there too. Note that: $ log 'modifies("set:modified()")' is different from: $ log 'modifies("*")' because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences. Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>
-
Matt Mackall authored
-
- Apr 25, 2012
-
-
Wagner Bruna authored
-
- Apr 24, 2012
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Apr 22, 2012
-
-
Matt Harbison authored
Summary and commit use dirty() to check the status of a subrepository, so this overrides dirty() in the subrepo in the same manner as status() to check the large files instead of their standins. Previously, if only a large file was changed in a subrepo, summary in the top level repo would not report the subrepo was dirty and commit -S would report nothing changed. If any type of file was changed in the top repo and only a large file in the subrepo, commit -S would not commit the changes to the subrepo.
-
Matt Harbison authored
Wrapping the status command will only invoke overridestatus() and set the lfstatus field for the top level repository. Wrapping the status function is required to set the field on child repositories. Previously, status -S would report large files in a subrepo as '?' regardless of their actual states, and was inconsistent with what status would report from within that subrepo.
-
- Apr 25, 2012
-
-
Katsunori FUJIWARA authored
on some non "en" locale environments, "hg convert" is aborted, because "util.parsedate()" fails. it fails in "memctx.__init__()" called by "putcommit()" of "convert". in "hg convert", datetimes gotten from source repository are usually formatted by "util.datestr()" with default format "%a %b %d %H:%M:%S %Y %1%2". but on some environments, "%a" and "%b" may cause locale sensitive string, and such string may cause parse error in "util.parsedate()". this path uses "%Y-%m-%d %H:%M:%S %1%2" as intermediate representation format for datetimes, because it consists only of locale insensitive elements. datetimes in above format are only used for passing them from conversion logic to memctx object, so it doesn't have to be formatted by locale sensitive one. this patch just avoids locale sensitivity problem of "datestr()" and "parsedate()" combintion.
-