[RFC] [PATCH] svn subrepo bug

[Carter, Eli]

(Original email was sent to the wrong list, sorry.  For those just joining us, the original is quoted below.)

This is related to issue 2968
http://mercurial.selenic.com/bts/issue2968

There are 3 patches here for discussion purposes, none are ready for inclusion.

minimal-testcase.patch is just a testcase to demonstrate the problem described in issue 2968
messy-bugfix-idea-1.patch is the large change I wound up with, with all the debugging cruft and false starts, and a change to what is stored in .hgsubstate.
bugfix-idea-2.patch is an initial stab at the problem at a deeper level, but it also causes other tests to fail.  I haven't even tried the other subrepo types with this change.

Am I headed down blind alleys here, or are there any suggestions of better approaches to solving this?

Thanks,

Eli

> -----Original Message-----
> From: Carter, Eli
> Sent: Tuesday, August 23, 2011 2:56 PM
> To: 'mercurial at selenic.com'
> Cc: durin42 at gmail.com
> Subject: [RFC] [PATCH] svn subrepo bug
> 
> This is related to issue 2968
> http://mercurial.selenic.com/bts/issue2968
> 
> The attached patch is a mess, and I'm not expecting it to be accepted in this
> form; it is intended to jumpstart discussion.
> 
> Last month, I contributed a fix for the svn subrepo support to handle the
> case where a branch is deleted and recreated, and a subrepo points to the
> old branch.  Hg was doing the wrong thing in that case.
> But that exposed another problem in Hg.
> 
> If you have a subdirectory in trunk in the svn repo (say ^/trunk/somesubdir)
> and you create a branch (svn copy ^/trunk ^/branches/my-new-branch), if
> you then point a subrepo at ^/branches/my-new-branch/somesubdir (and
> commit), updating Hg to that changeset will fail with an error due to the svn
> path not existing.  What is happening is that Hg is using the "Last changed
> rev" to identify what to check out, but since somesubdir has not been
> modified on the branch, that revision pre-dates the creation of the branch.
> So then Hg will attempt to checkout ^/branches/my-new-
> branch/somesubdir at oldrev and fail since that path didn't exist at that rev.
> This "worked" before my fix from last month because svn would follow back
> across the copy to do the update.
> 
> I expected this to be a straightforward change to make Hg use the rev
> instead of the last changed rev, but that broke some of the other testcases.
> If one commit in Hg has someurl at rev for a subrepo, and another commit has
> someotherurl at rev for that subrepo, updating between them sees that the
> revision matches, and misses the change in the url, and thus doesn't update
> the subrepo to the right state.
> 
> So this led me to embedding the url and the current revision (not the last
> modified revision) in the .hgsubstate value.  And further made me wonder
> (though I have not pursued it) if the .hgsub should list simply the
> subdirectories, and have .hgsubstate hold the subrepo (type, url, rev) state.
> 
> Either of those approaches is a significant change and one I expect to see
> some resistance to.  But I'm not seeing another solution that could work.
> 
> Thoughts, suggestions, pointers to things I'm missing, etc?
> 
> Eli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugfix-idea-2.patch
Type: application/octet-stream
Size: 2776 bytes
Desc: bugfix-idea-2.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110823/4d0b2bc4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messy-bugfix-idea-1.patch
Type: application/octet-stream
Size: 11952 bytes
Desc: messy-bugfix-idea-1.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110823/4d0b2bc4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal-testcase.patch
Type: application/octet-stream
Size: 1956 bytes
Desc: minimal-testcase.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110823/4d0b2bc4/attachment-0002.obj>