[RFC] [PATCH] svn subrepo bug

Carter, Eli Eli.Carter at tektronix.com
Wed Aug 24 09:34:56 CDT 2011


Here's an updated version of the patch + testcase for the second idea.

**NOTE THIS PATCH CAUSES TEST FAILURES**

I think at least part of the problem is that we have sub-repo state in two files, and either or both may be changed by a merge/update/commit, we need to deal with subrepo state if either changes, but we need both available when we deal with the subrepo state, ...
So I don't think the 'handle the substate when you find the first of .hgsub or .hgsubstate' approach is going to work; it may need to be done outside the loop or something.

Eli

> -----Original Message-----
> From: Carter, Eli
> Sent: Tuesday, August 23, 2011 5:16 PM
> To: mercurial-devel at selenic.com
> Cc: durin42 at gmail.com
> Subject: RE: [RFC] [PATCH] svn subrepo bug
> 
> (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-v2.patch
Type: application/octet-stream
Size: 6736 bytes
Desc: bugfix-idea-2-v2.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110824/7cfe8636/attachment.obj>


More information about the Mercurial-devel mailing list