On Mon, Jul 11, 2011 at 02:13:46PM +0100, Philip Martin wrote:
> Stefan Sperling <stsp_at_elego.de> writes:
>
> > We should allow invalid mergeinfo to exit the repository, e.g. in a dump
> > file. But input paths, such as svnadmin load, should refuse invalid mergeinfo.
>
> We have a similar problem with invalid svn:log (non-LF line-ends). In
> that case load fails with an error but sync corrects the value and
> completes the load. Simply refusing to sync was deemed insufficient.
This was because it was known that there were many repositories
out there with broken log messages. People had been committing invalid
log messages for years using Eclipse or other clients that didn't
normalise log messages properly.
We will only start tolerating invalid mergeinfo in 1.7 (cf. issue #3896).
If any invalid mergeinfo enters repositories used with 1.6.x servers
and clients, things immediately start falling over left and right.
There is no way not to notice this corruption (even simple updates can
start failing -- check the commits Paul made for issue #3896 to see in
how many places the 1.6.x client will start throwing fatal errors).
The 1.7 client tolerates invalid mergeinfo so that users who run into
this problem can upgrade their client to continue running operations
that do not require valid mergeinfo, until corrupted mergeinfo has been
fixed.
But there are *zero* known cases of such corruption in the wild.
Maybe it has already happened somewhere, but I have heard of no
such reports. It requires some smart person misusing git-svn's --mergeinfo
option, or some other custom client that sends invalid mergeinfo via
the RA layer directly. Clients using the libsvn_client API cannot
commit bad mergeinfo.
> > Maybe we should provide a way to fix invalid mergeinfo in dump files.
> > One existing but no officially supported method is svndumptool
> > http://svn.borg.ch/svndumptool/
>
> I've never used it, but I suppose it would work. Is that a good enough
> solution? Invalid mergeinfo is harder to fix than an invalid log
> message, because the validity rules are much more complex. Do we advise
> users to delete it? To analyse the failure and tweak it to be valid?
I would say proper analysis and tweaking is always preferred over deletion.
I guess that in practice most users would resort to simply deleting
invalid mergeinfo. But that only means that some merges will flag spurious
conflicts. Which is not a bad trade-off at all since 1.6.x clients are
basically unable to use the repository when faced with invalid mergeinfo.
The proper approach also depends on the kind of corruption (e.g. a simple
typo vs. garbage data).
Received on 2011-07-11 15:46:39 CEST