git-svn breakage on repository rename

git-svn breakage on repository rename

[Guido Stevens]

Hi Eric e.a.,

I have a weird git-svn corner case that might interest you (or not at 
all). I'd appreciate any help or hints for moving beyond this problem.

I'm using git-svn to do a full commit history analysis of the Zope + 
Plone CMS code bases as part of a research project with the University 
of Nottingham into open source knowledge dynamics.

One of the repositories I'm importing breaks with a "Checksum mismatch", 
indicating a corruption. However, this error message occurs exactly at 
the point where the repository was renamed: from "Products.CMFPlone" to 
"Plone" (22715->22716). (Yes, it's the Plone core itself that resists 
analysis :-()

The git-svn url for the later commits would be:
   http://svn-mirror.plone.org/svn/plone/Plone/trunk

Whereas an older part of the code base lives at:
   http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk

Funny thing is, git-svn detects this rename upfront but then breaks
anyway. Which raises the questions:

- is this breakage caused by the rename?

- or does git-svn handle the rename, and there is an actual corruption?

- is there any way I can work around this and get a valid or semi-valid
git history for this project?

I don't mind missing a few commits, since I'm not doing code development
on this repository, only statistical analysis.

Solving this would also be helpful for anyone who wants to work on Plone 
development through git rather than through raw svn.

:*CU#

----------------------------------------------------
To reconstruct this error:
----------------------------------------------------

$ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
$ cd Plone
$ git svn fetch

... Error message: (reformatted to wrap 78 cols):

Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/4.0 =>
https://svn.plone.org/svn/plone/Plone/trunk, 30966

Initializing parent: git-svn@30966

Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.3 =>
https://svn.plone.org/svn/plone/Plone/branches/4.0, 27288

Initializing parent: git-svn@27288

Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.2 =>
https://svn.plone.org/svn/plone/Plone/branches/3.3, 25119

Initializing parent: git-svn@25119

Found possible branch point:
https://svn.plone.org/svn/plone/Plone/branches/3.1 =>
https://svn.plone.org/svn/plone/Plone/branches/3.2, 22725

Initializing parent: git-svn@22725

branch_from: /Products.CMFPlone => /Products.CMFPlone/branches/3.1

Found possible branch point:
https://svn.plone.org/svn/plone/Products.CMFPlone/branches/3.1 =>
https://svn.plone.org/svn/plone/Plone/branches/3.1, 22715

Initializing parent: git-svn@22715

Found branch parent: (git-svn@22725)
e477345f83a0f2cc7e27348e01493a841c9cd587

Following parent with do_switch

Checksum mismatch: Products/CMFPlone/HISTORY.txt
expected: 69106809d879e7370dd133c7ba338670
     got: 7b1a0641d429f0c567acf7a3a4be5a45


-- 
***   Guido A.J. Stevens        ***   tel: +31.43.3618933    ***
***   guido.stevens@cosent.net  ***   Postbus 619            ***
***   http://www.cosent.nl      ***   6200 AP  Maastricht    ***

             s h a r i n g    m a k e s    s e n s e

Re: git-svn breakage on repository rename

[Eric Wong]

Guido Stevens <guido.stevens@cosent.net> wrote:
> Hi Eric e.a.,
>
> I have a weird git-svn corner case that might interest you (or not at  
> all). I'd appreciate any help or hints for moving beyond this problem.
>
> I'm using git-svn to do a full commit history analysis of the Zope +  
> Plone CMS code bases as part of a research project with the University  
> of Nottingham into open source knowledge dynamics.
>
> One of the repositories I'm importing breaks with a "Checksum mismatch",  
> indicating a corruption. However, this error message occurs exactly at  
> the point where the repository was renamed: from "Products.CMFPlone" to  
> "Plone" (22715->22716). (Yes, it's the Plone core itself that resists  
> analysis :-()
>
> The git-svn url for the later commits would be:
>   http://svn-mirror.plone.org/svn/plone/Plone/trunk
>
> Whereas an older part of the code base lives at:
>   http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk
>
> Funny thing is, git-svn detects this rename upfront but then breaks
> anyway. Which raises the questions:
>
> - is this breakage caused by the rename?

Hi Guido,

Yes.  By default, git svn without --stdlayout does not attempt
to determine a repository root so parent following can be done.
On the other hand, Plone does appear to use a standard SVN layout.

> - or does git-svn handle the rename, and there is an actual corruption?

It should, let me know if the example I give below doesn't work

It looks like a big repo and they're worried about bandwidth:
"Do not make a checkout of the entire repository! This is likely to
  get you blacklisted."
(ref: http://dev.plone.org/plone/wiki/RepoInfo)

> - is there any way I can work around this and get a valid or semi-valid
> git history for this project?
>
> I don't mind missing a few commits, since I'm not doing code development
> on this repository, only statistical analysis.

I would mind very much if git svn missed commits :>

> Solving this would also be helpful for anyone who wants to work on Plone  
> development through git rather than through raw svn.
>
> :*CU#
>
> ----------------------------------------------------
> To reconstruct this error:
> ----------------------------------------------------
>
> $ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
> $ cd Plone
> $ git svn fetch

Since Plone appears to use a standard trunk/branches/tags layout
recommended by SVN developers, can you try this instead?:

  git svn clone -s http://svn-mirror.plone.org/svn/plone/Plone

If you don't care about branches/tags at all, you can also try

  git svn clone --no-follow-parent \
    https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone


Also, in the future it'd be nice to know which version of git svn
you're using since bugs may be fixed in a newer version.  Thanks!

-- 
Eric Wong

Re: git-svn breakage on repository rename

[Guido Stevens]

Eric, thanks!

Plone admins: I can now confirm it was not a svn corruption. Adding the 
"--no-follow-parent" switch to git svn clone makes it possible to check 
out the Plone svn into git -- at least the commits since the rename.

That one might be relevant for anybody who wants to contribute to the 
Plone code base from a git-centered workflow.

Thanks everybody for helping to solve this problem! I can now integrate 
the analysis of Products.CMFPlone into the overall Plone ecosystem 
analysis, and it would have been very awkward not to be able to do that 
because of this renaming issue. Again: thanks.

:*CU#

Eric Wong wrote:
> Guido Stevens <guido.stevens@cosent.net> wrote:
>> ----------------------------------------------------
>> To reconstruct this error:
>> ----------------------------------------------------
>>
>> $ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
>> $ cd Plone
>> $ git svn fetch
> 
> Since Plone appears to use a standard trunk/branches/tags layout
> recommended by SVN developers, can you try this instead?:
> 
>   git svn clone -s http://svn-mirror.plone.org/svn/plone/Plone

That one breaks completely, silently.

> 
> If you don't care about branches/tags at all, you can also try
> 
>   git svn clone --no-follow-parent \
>     https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone

Yep, that one does the trick.

It does what it says though: it stops at the rename boundary 
22715->22716. Luckily I can do other checkouts on the other names that 
this package has had and complete my analysis anyway.

:*CU#
-- 
***   Guido A.J. Stevens        ***   tel: +31.43.3618933    ***
***   guido.stevens@cosent.nl   ***   Postbus 619            ***
***   http://www.cosent.nl      ***   6200 AP  Maastricht    ***

             s h a r i n g    m a k e s    s e n s e

	

Re: [Admins] Re: git-svn breakage on repository rename

[Jérôme Petazzoni]

Guido Stevens wrote:
> Thanks everybody for helping to solve this problem! I can now integrate 
> the analysis of Products.CMFPlone into the overall Plone ecosystem 
> analysis, and it would have been very awkward not to be able to do that 
> because of this renaming issue. Again: thanks.
>   

You're very welcome :-)