[RFC] [PATCH] svn subrepo bug

[Carter, Eli]

Third idea.... which interacts badly with mq for some reason, causing a test failure.

Pointers appreciated...

Eli

> -----Original Message-----
> From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
> bounces at selenic.com] On Behalf Of Carter, Eli
> Sent: Wednesday, August 24, 2011 9:35 AM
> To: mercurial-devel at selenic.com
> Cc: durin42 at gmail.com
> Subject: RE: [RFC] [PATCH] svn subrepo bug
> 
> 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-3-v1.patch
Type: application/octet-stream
Size: 5101 bytes
Desc: bugfix-idea-3-v1.patch
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110824/b601117e/attachment.obj>