> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: zondag 15 oktober 2017 21:28
> To: Ryan Schmidt <subversion-2016_at_ryandesign.com>
> Cc: Subversion Users <users_at_subversion.apache.org>
> Subject: Re: GitHub svn bridge corrupting working copies
>
> Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500:
> > On Oct 15, 2017, at 13:07, Daniel Shahaf wrote:
> > > Ryan Schmidt wrote on Sun, 15 Oct 2017 12:49 -0500:
> > >> And the problem will just occur again sometime later with a different
> node. The node it complains about is always a directory that someone else
> committed to recently, [...]
> > >
> > > Have you looked at these commits? Is there anything unusual in them,
> > > e.g., do they involve renames?
> >
> > Nothing unusual; just modifying one file and adding another:
> >
> > https://github.com/macports/macports-
> ports/commit/2198debd25b02bcf7f6b17f79b415690449a85f0
>
> Okay, so perhaps the problem has to do with revisions that add new
> files.
>
> > Somehow I don't think specific revisions are the problem. I mean, I
> > can now check out a new working copy at revision 139307 and
> > successfully update it to 139308. Meanwhile, on our server, once,
> > back in August, it encountered a corruption already halfway through
> > the process of checking out a new working copy. And on the next
> > checkout attempt it worked.
>
> Indeed, there is little we can do without knowledge of the bridge.
> There is any number of ways in which these observations might be
> confounders.
>
> > > You might be able to reproduce the problem by backdating your working
> > > copy, 'svn up -r N-1 && svn up -r N kde'.
> >
> > Inside the kde directory, I ran:
> ⋮
> > $ svn up -r 139308
> > Updating '.':
> > UU kdepimlibs4/Portfile
> > Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An
> obstructing working copy was found
>
> That's interesting; why would there be an obstruction?
>
> Maybe a file by this name already existed at some point, and was not
> removed cleanly?
>
> Or perhaps github reported the 'add' to the client twice?
One probable cause for this would be that they somehow changed the revision number to hash mapping. I would hope they change the repository UUID in this case, but given how easy it is to change history in git, I wouldn't count on this.
Is this problem reproducible on a clean checkout from the same base revision?
Bert
Received on 2017-10-16 15:01:25 CEST