[RFC] [PATCH] svn subrepo bug

Carter, Eli Eli.Carter at tektronix.com
Tue Aug 23 19:55:37 UTC 2011


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: hg-svn-subrepo-bugfix-v0.patch
Type: application/octet-stream
Size: 11910 bytes
Desc: hg-svn-subrepo-bugfix-v0.patch
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110823/d91e1295/attachment-0002.obj>


More information about the Mercurial mailing list