On Oct 16, 2017, at 08:01, Bert Huijben wrote:
> 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.
>
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: zondag 15 oktober 2017 21:28
> To: Ryan Schmidt
> Cc: Subversion Users
> Subject: Re: GitHub svn bridge corrupting working copies
>
> Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14
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 directo
Thanks for your suggestions!
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
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 t
Hi, I'm sure this is GitHub's problem, because it happens only when accessing a
git repository through the GitHub Subversion bridge using the Subversion
client, but it's been months since I reported the problem to them and they
haven't fixed it so I thought I'd ask here if anybody has any idea h
