svnsync discrepancies again

[Ulrich Spörlein]

On Thu, 2020-07-09 at 15:46:52 -0400, Ed Maste wrote:
> > > Not sure I'd call this "garbage" nor would I immediately assume that
> > > we've decided to "point cluster machines at garbage" and "give the rest
> > > of the world the good stuff."
> 
> Garbage is perhaps unnecessarily inflammatory, so let's avoid calling
> it that. However, I hope we all agree that if we have multiple copies
> of the SVN repo they must contain the same data and metadata.
> 
> We had this problem often in the past and I thought it was now "fixed"
> by the scripts that run svnsync? Is the issue just that we can only
> ever have one svnsync generation?

Maybe it's inflammatory, maybe it was lost in translation. Maybe I'm
just really angry about the time I've wasted chasing after what ended up
being svnsync's fault more than once.

It has 1 job and it fails to do that 1 job consistently. That is really
frustrating.

I wish we would not use svnsync for the mirrors. rsync(1) is a perfectly
good alternative that wouldn't randomly munge the data.

I also wish we wouldn't even mirror the repo in the first place. We're
turning a centralized VCS into a decentralized one, that makes no sense.

The added mirrors might add some sense of security I guess, other than
that they probably have wasted more time and effort than we have gained
by them :/

> 
> > - where is the actual canonical source of our SVN and
> > - how can I get access to it from both a machine inside the cluster as
> >   well as outside?
> 
> Having access to a SVN repository that's guaranteed to have the
> correct data and metadata is a requirement for the svn-git migration
> process. so I hope someone can answer those two shortly.

Yes please. You might wonder why I'm so angry because of a 2s time
delta, but svnsync is also known to not copy the author correctly and
with git everything get's hashed, so the result would be a totally
different repo. We don't want that.

Thanks
Uli