> -----Original Message----- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zondag 15 oktober 2017 21:28 > To: Ryan Schmidt <subversion-2...@ryandesign.com> > Cc: Subversion Users <users@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