Re: branch creation uses wrong starting point

Hi Michael,

On Thu, Apr 29, 2010 at 09:38:14AM +0200, Michael Haggerty wrote:

> > I'm preparing migration of a rather large codebase and I came across an
> > issue. I'll try to summarize it briefly.
> > 
> > Suppose, I've got three branches in CVS (plus HEAD) with the following
> > anchestry:
> > HEAD
> > +- 5_4_branch
> > ...+- 5_4_customer_production_branch
> > ......+- 5_4_customer_test_branch
> > 
> > I'm mapping these to
> > /c4u/MODULES
> > /c4u/5.4/MODULES
> > /customer/old_branches/5_4_customer_production/MODULES
> > /customer/old_branches/5_4_customer_test/MODULES
> > 
> > I looked into symbol-info.txt and found that all parent-relations are
> > correctly recognized:
> > 0     5_4_branch            branch     c4u/5.4/MODULES .trunk.
> > 0     5_4_customer_production_branch branch customer/old_branches/5_4_customer_production/MODULES 5_4_branch
> > 0     5_4_customer_test_branch    branch customer/old_branches/5_4_customer_test/MODULES 5_4_customer_production_branch
> > 
> > But it looks like the commit for the creation of
> > "5_4_customer_test_branch" is wrong. I come to that conclusion since
> > svnsync-ing the converted repository fails and reports a missing file
> > right at that commit. The log message also does not make sense:
> > 
> > ----
> > r24870 | cvs2svn | 2009-09-30 10:51:17 +0200 (Wed, 30 Sep 2009) | 2 lines
> > Changed paths:
> >    A /customer/old_branches/5_4_customer_test
> >    A /customer/old_branches/5_4_customer_test/MODULES (from /c4u/MODULES:15273)
> > [...]
> > This commit was manufactured by cvs2svn to create branch
> > '5_4_customer_test_branch'.
> > ----
> > 
> > It looks like it copies the test-branch from trunk instead of it's
> > parent which has just been correctly created the revision before:
> > ------------------------------------------------------------------------
> > r24869 | cvs2svn | 2009-09-30 10:51:16 +0200 (Wed, 30 Sep 2009) | 2 lines
> > Changed paths:
> >    A /customer/old_branches/5_4_customer_production
> >    A /customer/old_branches/5_4_customer_production/MODULES (from /c4u/5.4/MODULES:24860)
> >    D /customer/old_branches/5_4_customer_production/MODULES/c4u_tools 
> > 
> > This commit was manufactured by cvs2svn to create branch
> > '5_4_customer_production_branch'.
> > ------------------------------------------------------------------------
> > -> copied correctly from 5_4_branch, removing that one module which does
> > not have that branch.
> 
> Your analysis is helpful, but it would be more helpful if you would also
> provide a test repository that we can use to reproduce your problem.
> Reasoning about problems like this is much easier with a concrete
> example.  See the FAQ for instructions for how to make a test repo.
 
I attached a test repository (but didn't alter the branch and module
names as done above as I did for the first mail). There is a conversion
script included. Feel free to add the ManualRegexpSymbolRule from
c4u_functions to cvs2svn.

> > I'm a bit lost and suspect a cvs2svn bug (I'm using 2.3.0). Is it worth
> > to try cvs2svn from trunk?
> 
> It can't hurt, though offhand I can't think of any changes in trunk that
> would affect this.
 
I tried and the resulting repository was different, but still not
correct. I'm getting the same error with svnsync.

> > I was able to reproduce the problem using a clean repository, performing
> > only the following operations: [...]
> > -> both production and test branch are created at the same time, with no
> > changes inbetween. It looks like cvs2svn uses the CVS-revision number
> > for determining from where to copy files, but they do not show the
> > parent-child relationship:
> > cvs log
> >     5_4_customer_test_branch:       1.1.1.1.2.1.0.4
> >     5_4_customer_production_branch: 1.1.1.1.2.1.0.2
> >     5_4_branch: 1.1.1.1.0.2

The real branch names are now "open_eis_5_4_branch" and
"open_eis_5_4_mf_*_branch"

> There is no unambiguous way to determine the relationship between
> branches in cases like these.  So cvs2svn uses some heuristics, *not*
> just basing its decision on the version numbers.  (These heuristics
> don't work so well for vendor branches, so if your real example involves
> vendor branches that could be part of the problem.)

We do not use vendor branches (apart from initial import). I had to do
one change/commit to the test repository before branching or cvs2svn
wouldn't get the open_eis_5_4_branch right because it got confused by
the dummy vendor branch used during import.

> It is alarming that svnsync reports an error on the converted
> repository, and we should get to the bottom of that problem.  It is
> definitely a bug, either in "svnadmin load", or in svnsync, or in
> cvs2svn *and* "svnadmin load" (because "svnadmin load" should refuse to
> load invalid data into the repository regardless of where it comes from).
> 
> But otherwise the most important criterion for the correctness of a
> conversion is whether checking a branch/tag out of Subversion gives the
> same files and contents as checking the same branch/tag out of CVS.  Is
> this the case with your repo?

No. Not with my complex test case - there is a whole subdirectory
missing from the branch (since it's based on HEAD, then tried to fixup
instead of being based on it's real parent).

Maybe the fix would be to adhere to the branch-parent relationship for
manufacturing branches?

Thanks,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.lichtkreis-chemnitz.de
www.tisc.de