You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/12/19 03:05:30 UTC

Re: entry and wcprops stored in repository(!)

On Thu, Dec 19, 2002 at 03:24:42AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
> >Two more entry properties. Big Badness.
> >
> >All of those entry props and the wcprop need to be cleaned out of the
> >repository.
>
> Gentlemen, we have another First. Our first repository data corruption
> ever. Do we break out the champagne, or the thumbscrews?

Well, not really. The client just committed "bad" data. The repository
faithfully stored it, and is returning it. I wouldn't exactly call that
corruption. If you did, then you'd also have to call out those bad-delta
commits that we've had in the past.

As far as I can tell, this *only* affects propchange-email.pl (as of
revision 4046). There is no other dir/file in HEAD that has entry or wcprops
on it, and there are NO dirs/files in rev 4045 that have the bad data.

Another interesting data point from Ben: rev 4046 was only a propset. Being
a single file, it is also possible that it was done using 'svn propset'
against a URL. This means there could be bugs in commits that are only
propsets, or in the 'svn propset URL' code.

Next question is what to do about propchange-email.pl ? Just edit the sucker
to remove those properties? Or do we dump/edit/load to fix them in the
historical record?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: entry and wcprops stored in repository(!)

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 18, 2002 at 07:05:30PM -0800, Greg Stein wrote:
>...
> Another interesting data point from Ben: rev 4046 was only a propset. Being
> a single file, it is also possible that it was done using 'svn propset'
> against a URL. This means there could be bugs in commits that are only
> propsets, or in the 'svn propset URL' code.

Oops. There was a text change. So never mind this.

But it *was* possibly a merge. Blair? Any further info? Was it actually an
'svn merge' ? I seem to recall some bugs w.r.t merge and properties.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: entry and wcprops stored in repository(!)

Posted by Blair Zajac <bl...@orcaware.com>.
Greg Stein wrote:
> 
> On Thu, Dec 19, 2002 at 03:24:42AM +0100, Branko Cibej wrote:
> > Greg Stein wrote:
> > >Two more entry properties. Big Badness.
> > >
> > >All of those entry props and the wcprop need to be cleaned out of the
> > >repository.
> >
> > Gentlemen, we have another First. Our first repository data corruption
> > ever. Do we break out the champagne, or the thumbscrews?
> 
> Well, not really. The client just committed "bad" data. The repository
> faithfully stored it, and is returning it. I wouldn't exactly call that
> corruption. If you did, then you'd also have to call out those bad-delta
> commits that we've had in the past.
> 
> As far as I can tell, this *only* affects propchange-email.pl (as of
> revision 4046). There is no other dir/file in HEAD that has entry or wcprops
> on it, and there are NO dirs/files in rev 4045 that have the bad data.
> 
> Another interesting data point from Ben: rev 4046 was only a propset. Being
> a single file, it is also possible that it was done using 'svn propset'
> against a URL. This means there could be bugs in commits that are only
> propsets, or in the 'svn propset URL' code.

I did change the file in the commit using svn merge; svn ci.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org