[issue2405] Update causes unwanted subrepo update/merge
Martin Geisler
bugs at mercurial.selenic.com
Mon Sep 27 13:32:50 UTC 2010
New submission from Martin Geisler <mg at lazybytes.net>:
The script below shows an unfortunate behavior in how subrepos are merged
upon update. It creates three revisions in an outer repo and an inner
subrepo so that:
main 2: 0fc3cdfccbc8 --> sub 2: 97dc77eda23d
main 1: 5d202505eb64 --> sub 1: 8514e0ba703c
main 0: 56b51e4cf504 --> sub 0: a2eda9ba59e6
where the arrows indicate which subrepo revision each main repo revision
points to:
$ hg init
$ hg init sub
$ echo 'sub = sub' > .hgsub
$ hg add .hgsub
$ echo x0 > x
$ echo y0 > sub/y
$ hg add -S
adding x
adding sub/y
$ hg commit -m r0
committing subrepository sub
$ echo x1 > x
$ echo y1 > sub/y
$ hg commit -m r1
committing subrepository sub
$ echo x2 > x
$ echo y2 > sub/y
$ hg commit -m r2
committing subrepository sub
It then updates the repo to rev 1, and the subrepo to rev 0.
$ hg -q update 1
$ hg -q -R sub update 0
The problem comes when we update the main repository. We correctly detect
that the subrepo is dirty and should be merged, but since it is only dirty
with respect to .hgsubstate, the merge ends up being an update to 97dc77eda23d:
$ hg update --debug 2
searching for copies back to rev 2
resolving manifests
overwrite False partial False
ancestor 5d202505eb64 local 5d202505eb64+ remote 0fc3cdfccbc8
x: remote is newer -> g
.hgsubstate: versions differ -> m
updating: .hgsubstate 1/2 files (50.00%)
subrepo merge 5d202505eb64+ 0fc3cdfccbc8 5d202505eb64
subrepo sub: both sides changed, merge with sub:97dc77eda23d...:hg
updating subrepo sub
searching for copies back to rev 1
resolving manifests
overwrite False partial False
ancestor a2eda9ba59e6 local a2eda9ba59e6+ remote 97dc77eda23d
y: remote is newer -> g
updating: y 1/1 files (100.00%)
getting y
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
updating: x 2/2 files (100.00%)
getting x
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat .hgsubstate
8514e0ba703cdb0dcc5c92beb6c534ec8e7cb34b sub
$ hg -R sub id
97dc77eda23d tip
So after the update to rev 2, .hgsubstate file corresponds to rev 1 and the
subrepo corresponds to rev 2.
The expected behavior was to leave the subrepo alone at its rev 0. We
normally merge a dirty working copy with the target revision, and here the
user "edited" the .hgsubstate file by updating inside the subrepo. Merging
this dirty .hgsubstate file technically generates a conflict here (user put
in content from rev 0 and updates to rev 2).
So maybe we could put in a prompt, though that will be highly annoying if
you have 30 subrepos that you have taken back in time because you are
searching for a bug in the remaining parts of the code.
----------
messages: 13770
nosy: kiilerix, mg, mpm, sedlock
priority: bug
status: unread
title: Update causes unwanted subrepo update/merge
____________________________________________________
Mercurial issue tracker <bugs at mercurial.selenic.com>
<http://mercurial.selenic.com/bts/issue2405>
____________________________________________________
More information about the Mercurial-devel
mailing list