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 00:56:50 UTC
entry and wcprops stored in repository(!) (was: bug? "Delta source ended unexpectedly")
On Wed, Dec 18, 2002 at 08:00:26PM +0000, Philip Martin wrote:
>...
> PROPFIND /repos/svn/!svn/ver/4111/trunk/tools/hook-scripts/propchange-email.pl
>...
> <D:href>/repos/svn/!svn/bln/4111</D:href>
This is wrong. Why is the href for the baseline coming back when a PROPFIND
for a version resource was requested?!
> <D:propstat>
> <D:prop>
> <S:entry:last-author>blair</S:entry:last-author>
> <S:wc:ra_dav:version-url>/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commi
> t-email.pl</S:wc:ra_dav:version-url>
Woah! Are those entry properties? And a wcprop?
There is the problem. ra_dav is probably writing the correct value into
wcprops, but this property comes down from the server and overwrites it.
Bad bad. How did that get onto the server? Most likely some of the recent
monkeying with property handling on the client ended up submitting this
property as a "real" value during some commit. Or maybe somebody was working
on the stuff, had a broken client, and committed a change. Of course, how it
even happened to end up with a commit-email prop is beyond me.
> <S:executable>on</S:executable>
> <S:keywords>HeadURL LastChangedBy LastChangedDate LastChangedRevision</S:keyword
> s>
> <S:entry:committed-rev>3765</S:entry:committed-rev>
> <S:entry:committed-date>2002-11-12T20:13:12.742465Z</S:entry:committed-date>
Two more entry properties. Big Badness.
All of those entry props and the wcprop need to be cleaned out of the
repository.
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
Re: entry and wcprops stored in repository(!)
Posted by Greg Stein <gs...@lyra.org>.
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(!) (was: bug? "Delta
source ended unexpectedly")
Posted by Branko Čibej <br...@xbc.nu>.
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?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> 2. Fix the repository. Gstein used his magick python scripts to scan
> our repository, and only this one file has the bad props. Either
> we remove the bogus props from HEAD, or we do dump/load sorcery
> and attempt to change history.
I can take care of this pronto.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ALL DEVELOPERS -- FIX YOUR BUSTED WC NOW!
Posted by cm...@collab.net.
"Glenn A. Thompson" <gt...@cdr.net> writes:
> hey,
>
> Will this fix cause a problem for people boot strapping?
> just curious.
Presumably, folks bootstrap because they have no working copies.
They're fine. All the 'rm -rf hook-scripts; svn up' stuff was just a
workaround to prevent folks with working copies from having to check
out whole new working copies.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ALL DEVELOPERS -- FIX YOUR BUSTED WC NOW!
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
hey,
Will this fix cause a problem for people boot strapping?
just curious.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
ALL DEVELOPERS -- FIX YOUR BUSTED WC NOW!
Posted by cm...@collab.net.
As was pointed out earlier, due to a client bug, some nasty stuff got
into the Subversion source repository. ***THIS WAS NOT A CASE OF
REPOS CORRUPTION***. That is, the repository succeeded in performing
the task the client asked it to do, and no data was damaged or lost or
anything. However, it was certainly a circumstance which highlights a
client frailty, and it has probably affected every developer with a
relatively up-to-date Subversion working copy.
That said, Ben Collins-Sussman <su...@collab.net> writes:
> So here's what we need to do from here:
>
> 1. Make sure everyone is running a post r4023 client, so nobody gets
> bitten by issue 1012, accidentally creating bad props.
You heard the man. Upgrade your working copies to post-4023, and
rebuild your Subversion clients.
> 2. Fix the repository. Gstein used his magick python scripts to scan
> our repository, and only this one file has the bad props. Either
> we remove the bogus props from HEAD, or we do dump/load sorcery
> and attempt to change history.
This has been done. As far the repository is concerned, the
propchanges never happened in that revision (I re-added them
afterwards).
> 3. Tell everyone to 'rm -rf hook-scripts; svn up'. It's not enough
> to simply toss the wcprop cache. There's bogus liveprop data
> sitting in the entry itself (the CR is wrong, for example.)
> Easier to rebuild the whole directory.
This is the important part. ALL DEVELOPERS should do this.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source
ended unexpectedly")
Posted by Blair Zajac <bl...@orcaware.com>.
cmpilato@collab.net wrote:
>
> Blair Zajac <bl...@orcaware.com> writes:
>
> > I have a public Subversion repository that is used by people that
> > don't have the time or the inclination to rebuild Subversion when
> > something like this happens, and I'm concerned about a client doing
> > something similar to my repository.
>
> Upgrade your repository-touching code to HEAD, and any bogus client
> commits of this sort should fail with this message:
>
> Storage of non-regular property 'svn:wc:foo' is disallowed through
> the repository interface, and could indicate a bug in your client.
That's great!
Thanks,
Blair
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by cm...@collab.net.
Blair Zajac <bl...@orcaware.com> writes:
> I have a public Subversion repository that is used by people that
> don't have the time or the inclination to rebuild Subversion when
> something like this happens, and I'm concerned about a client doing
> something similar to my repository.
Upgrade your repository-touching code to HEAD, and any bogus client
commits of this sort should fail with this message:
Storage of non-regular property 'svn:wc:foo' is disallowed through
the repository interface, and could indicate a bug in your client.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by Ben Collins-Sussman <su...@collab.net>.
Blair Zajac <bl...@orcaware.com> writes:
> >
> > 1. Make sure everyone is running a post r4023 client, so nobody gets
> > bitten by issue 1012, accidentally creating bad props.
>
> I have a public Subversion repository that is used by people that
> don't have the time or the inclination to rebuild Subversion when
> something like this happens, and I'm concerned about a client doing
> something similar to my repository.
I think what we want to do is create a svn_repos_* wrapper around
svn_fs_change_node_prop(). This wrapper would automatically prevent
any svn:wc: or svn:entry: props from coming through (since we control
the svn: namespace anyway, it's easy to screen out the subspaces).
Then it's just a matter of making the libsvn_repos commit-editor (used
by ra_local and ra_svn) and mod_dav_svn always use
svn_repos_change_node_prop instead of svn_fs_change_node_prop().
I think cmpilato is making this change right now. When it's done,
it's just a matter of upgrading your server code, and your repository
will be "safe" from clients with bug #1012.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source
ended unexpectedly")
Posted by Blair Zajac <bl...@orcaware.com>.
Rafael Garcia-Suarez wrote:
> > I think this would have to be something the server does and not
> > something you'd check in Apache, because if you did this in Apache,
> > svnserve would not be protected.
>
> The version/revision number could still be useful for the http
> client, e.g. sending it in the User-Agent header. So apache could
> log it, or deny access (for some methods) based on it, etc.
The client already sends it along (this is from my access_log):
A.B.C.D - - [19/Dec/2002:07:43:02 -0800] "PROPFIND /repos/trunk/orca
HTTP/1.1" 207 558 "-" "neon/0.21.2 SVN/0.14.1 (r2927)"
Boy, that's an old client.
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
Re: entry and wcprops stored in repository(!) (was: bug? "Delta source ended unexpectedly")
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Blair Zajac <bl...@orcaware.com> wrote:
>
> I have a public Subversion repository that is used by people that
> don't have the time or the inclination to rebuild Subversion when
> something like this happens, and I'm concerned about a client doing
> something similar to my repository.
>
> Is there anyway for the me to have my Subversion server validate
> the Subversion client version number?
>
> This would be a good thing to have, and would be another reason to
> have the Subversion revision number compiled into the client in
> addition to the 0.XX.Y style revision number.
>
> The version check would occur all but the GET, OPTIONS, PROPFIND,
> REPORT methods, because you'd still like to have people check out
> the repository with an older client.
>
> I think this would have to be something the server does and not
> something you'd check in Apache, because if you did this in Apache,
> svnserve would not be protected.
The version/revision number could still be useful for the http
client, e.g. sending it in the User-Agent header. So apache could
log it, or deny access (for some methods) based on it, etc.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source
ended unexpectedly")
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
>
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > > How did you do the 'merge' for that revision?
> >
> > Bam! Issue 1012 is the culprit!
> >
> > It's already fixed, but I'll bet a huge sum that this is the exact bug
> > that caused blair's bogus wc. He didn't realize that he got extra
> > props, and then committed them.
>
> So here's what we need to do from here:
>
> 1. Make sure everyone is running a post r4023 client, so nobody gets
> bitten by issue 1012, accidentally creating bad props.
I have a public Subversion repository that is used by people that
don't have the time or the inclination to rebuild Subversion when
something like this happens, and I'm concerned about a client doing
something similar to my repository.
Is there anyway for the me to have my Subversion server validate
the Subversion client version number?
This would be a good thing to have, and would be another reason to
have the Subversion revision number compiled into the client in
addition to the 0.XX.Y style revision number.
The version check would occur all but the GET, OPTIONS, PROPFIND,
REPORT methods, because you'd still like to have people check out
the repository with an older client.
I think this would have to be something the server does and not
something you'd check in Apache, because if you did this in Apache,
svnserve would not be protected.
When the client accesses a server with svn://, does it send it's
version along?
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
Re: entry and wcprops stored in repository(!) (was: bug? "Delta source ended unexpectedly")
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > How did you do the 'merge' for that revision?
>
> Bam! Issue 1012 is the culprit!
>
> It's already fixed, but I'll bet a huge sum that this is the exact bug
> that caused blair's bogus wc. He didn't realize that he got extra
> props, and then committed them.
So here's what we need to do from here:
1. Make sure everyone is running a post r4023 client, so nobody gets
bitten by issue 1012, accidentally creating bad props.
2. Fix the repository. Gstein used his magick python scripts to scan
our repository, and only this one file has the bad props. Either
we remove the bogus props from HEAD, or we do dump/load sorcery
and attempt to change history.
3. Tell everyone to 'rm -rf hook-scripts; svn up'. It's not enough
to simply toss the wcprop cache. There's bogus liveprop data
sitting in the entry itself (the CR is wrong, for example.)
Easier to rebuild the whole directory.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source
ended unexpectedly")
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
>
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Ben Collins-Sussman <su...@collab.net> writes:
> >
> > > Somehow, the 'svn:wc:' props and 'svn:entry' props (which are "live"
> > > props normally generated by the RA layer) weren't properly filtered
> > > somewhere, so instead of being routed into an entries file or wcprop
> > > area, they got stored as normal "dead" props in blair's working copy.
> >
> > Blair, you out there? Is this true?
> >
> > Assuming you still have the same working copy as you did when you
> > committed r4046, does a 'svn pl -v propchange-email.pl' show bizarre
> > properties?
> >
> > How did you do the 'merge' for that revision?
>
> Bam! Issue 1012 is the culprit!
>
> It's already fixed, but I'll bet a huge sum that this is the exact bug
> that caused blair's bogus wc. He didn't realize that he got extra
> props, and then committed them.
Looking at the dates of this commit and of my subversion installs,
I used rev 3868 to do the commit.
Blair
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Somehow, the 'svn:wc:' props and 'svn:entry' props (which are "live"
> > props normally generated by the RA layer) weren't properly filtered
> > somewhere, so instead of being routed into an entries file or wcprop
> > area, they got stored as normal "dead" props in blair's working copy.
>
> Blair, you out there? Is this true?
>
> Assuming you still have the same working copy as you did when you
> committed r4046, does a 'svn pl -v propchange-email.pl' show bizarre
> properties?
>
> How did you do the 'merge' for that revision?
Bam! Issue 1012 is the culprit!
It's already fixed, but I'll bet a huge sum that this is the exact bug
that caused blair's bogus wc. He didn't realize that he got extra
props, and then committed them.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source
ended unexpectedly")
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
>
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Somehow, the 'svn:wc:' props and 'svn:entry' props (which are "live"
> > props normally generated by the RA layer) weren't properly filtered
> > somewhere, so instead of being routed into an entries file or wcprop
> > area, they got stored as normal "dead" props in blair's working copy.
>
> Blair, you out there? Is this true?
I was wondering how long before this was going to come back to me :)
Yes, I did a merge from 3955:3956 of tools/hook-scripts/commit-email.pl
to tools/hook-scripts/propchange-email.pl.
>
> Assuming you still have the same working copy as you did when you
> committed r4046, does a 'svn pl -v propchange-email.pl' show bizarre
> properties?
Yes:
% svn pl -v tools/hook-scripts/propchange-email.pl
Properties on 'tools/hook-scripts/propchange-email.pl':
svn:entry:last-author : blair
svn:wc:ra_dav:version-url : /repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
svn:executable : on
svn:keywords : HeadURL LastChangedBy LastChangedDate LastChangedRevision
svn:entry:committed-rev : 3765
svn:entry:committed-date : 2002-11-12T20:13:12.742465Z
> How did you do the 'merge' for that revision?
I don't have the command history, but I believe I did
svn merge -r 3955:3956 commit-email.pl propchange-email.pl
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
Re: entry and wcprops stored in repository(!) (was: bug? "Delta source ended unexpectedly")
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Somehow, the 'svn:wc:' props and 'svn:entry' props (which are "live"
> props normally generated by the RA layer) weren't properly filtered
> somewhere, so instead of being routed into an entries file or wcprop
> area, they got stored as normal "dead" props in blair's working copy.
Blair, you out there? Is this true?
Assuming you still have the same working copy as you did when you
committed r4046, does a 'svn pl -v propchange-email.pl' show bizarre
properties?
How did you do the 'merge' for that revision?
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Revision 4046 added those properties to propchange-email.pl on the server.
>
> Now to figure out how to find all the files with bad props and get rid of
> them...
We also need to figure out where this bug crept in.
Somehow, the 'svn:wc:' props and 'svn:entry' props (which are "live"
props normally generated by the RA layer) weren't properly filtered
somewhere, so instead of being routed into an entries file or wcprop
area, they got stored as normal "dead" props in blair's working copy.
Then he unknowingly committed them in r4046. Now whenever someone
checks out or updates that file, the bogus dead props overwrite the
correct live props.
Once we know where the filtering bug crept in, we know how far back to
look for bogus deadprops in our repository.
---------------------------------------------------------------------
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(!) (was: bug? "Delta source ended unexpectedly")
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Dec 18, 2002 at 04:56:50PM -0800, Greg Stein wrote:
>...
> > <D:propstat>
> > <D:prop>
> > <S:entry:last-author>blair</S:entry:last-author>
> > <S:wc:ra_dav:version-url>/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commi
> > t-email.pl</S:wc:ra_dav:version-url>
>
> Woah! Are those entry properties? And a wcprop?
>
> There is the problem. ra_dav is probably writing the correct value into
> wcprops, but this property comes down from the server and overwrites it.
>
> Bad bad. How did that get onto the server? Most likely some of the recent
> monkeying with property handling on the client ended up submitting this
> property as a "real" value during some commit. Or maybe somebody was working
> on the stuff, had a broken client, and committed a change. Of course, how it
> even happened to end up with a commit-email prop is beyond me.
Revision 4046 added those properties to propchange-email.pl on the server.
Now to figure out how to find all the files with bad props and get rid of
them...
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