subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: GitHub svn bridge corrupting working copies
Date Mon, 16 Oct 2017 13:01:17 GMT
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: zondag 15 oktober 2017 21:28
> To: Ryan Schmidt <subversion-2016@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


Mime
View raw message