You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Pool <mb...@samba.org> on 2002/12/18 05:50:11 UTC
bug? "Delta source ended unexpectedly"
I'm trying to update my Subversion tree using a local build
svn, version 0.16.0 (dev build)
compiled Dec 13 2002, 12:32:42
from trunk on that date.
It dies with
% svn up
svn: Incomplete data
svn: Delta source ended unexpectedly
I got an Ethereal capture of the transaction (for lack of anything
better to do.) This is attached.
If I extract and gunzip the response then it seems to be a complete
XML file. (Also attached.)
The same error occurs every time I try to update that wc. I've tried
svn cleanup to no effect. I can send a tarball of the wc if you want.
Using the same svn binary I can apparently get a new wc and then do an
update in there with no trouble. I can also update to 4110, and then
move forward to head with no trouble.
So I think something must be wrong in that wc. I didn't change
anything by hand, so possibly it's a svn bug that got it to this
state.
--
Martin
Re: bug? "Delta source ended unexpectedly"
Posted by Martin Pool <mb...@samba.org>.
On 18 Dec 2002, Karl Fogel <kf...@newton.ch.collab.net> wrote:
> Martin Pool <mb...@samba.org> writes:
> > % svn up
> > svn: Incomplete data
> > svn: Delta source ended unexpectedly
> >
> > I got an Ethereal capture of the transaction (for lack of anything
> > better to do.) This is attached.
> >
> > If I extract and gunzip the response then it seems to be a complete
> > XML file. (Also attached.)
> >
> > The same error occurs every time I try to update that wc. I've tried
> > svn cleanup to no effect. I can send a tarball of the wc if you want.
>
> Hmmmm. This can happen when a wcprop gets out of date.
>
> Save that working copy somewhere.
>
> Then, examine the version-resource-urls in .svn/wcprops/*. The format
> is
>
> K <keylen>
> keystring
> V <valuelen>
> valuestring
>
> so one property's name/value pair takes four lines. The file ends
> with "END".
>
> The values should be pretty self-explanatory. The question is, do
> they match the committed-revs given in the .svn/entries file? If not,
> you have out-of-date wcprops.
OK, I'll check...
> Working on issue #689 as fast as can... :-)
That sounds good.
In addition, I'd like some kind of checksumming on directory changes.
Conceptually the client might send a checksum of the XML .svn/entries
file, to protect against corrupt directories getting into the
repository because of svn bugs. I think it is probably more complex
in practice because the server after applying equivalent changes might
end up with different files. Mixed-version repositories probably make
it complicated too.
Presumably property changes need protection too.
Probably somebody already thought about these two but #689 only talks
about text changes so I thought I'd mention it.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Martin Pool <mb...@samba.org> writes:
>
>
>>% svn up
>>svn: Incomplete data
>>svn: Delta source ended unexpectedly
>>
>>I got an Ethereal capture of the transaction (for lack of anything
>>better to do.) This is attached.
>>
>>If I extract and gunzip the response then it seems to be a complete
>>XML file. (Also attached.)
>>
>>The same error occurs every time I try to update that wc. I've tried
>>svn cleanup to no effect. I can send a tarball of the wc if you want.
>>
>>
>
>Hmmmm. This can happen when a wcprop gets out of date.
>
I'm having the same problem om my HP-UX test box right now (that I can't
access, because some smarty "fixed" my password, dammit.).
>As to *how* this happened, that's a good question.
>
It must be something very basic, because that box didn't /ever/ do
anything but "svn up" in that working copy -- no commits, no partial
updates, no nothing.
Hm, except if the connection timed out sometime in the past. Well, count
another bug against libsvn_wc robustness. As if we didn't know.
--
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: bug? "Delta source ended unexpectedly"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Martin Pool <mb...@samba.org> writes:
> % svn up
> svn: Incomplete data
> svn: Delta source ended unexpectedly
>
> I got an Ethereal capture of the transaction (for lack of anything
> better to do.) This is attached.
>
> If I extract and gunzip the response then it seems to be a complete
> XML file. (Also attached.)
>
> The same error occurs every time I try to update that wc. I've tried
> svn cleanup to no effect. I can send a tarball of the wc if you want.
Hmmmm. This can happen when a wcprop gets out of date.
Save that working copy somewhere.
Then, examine the version-resource-urls in .svn/wcprops/*. The format
is
K <keylen>
keystring
V <valuelen>
valuestring
so one property's name/value pair takes four lines. The file ends
with "END".
The values should be pretty self-explanatory. The question is, do
they match the committed-revs given in the .svn/entries file? If not,
you have out-of-date wcprops.
If you blow away the bad version-url wcprops, I'll bet the update
works.
As to *how* this happened, that's a good question.
> Using the same svn binary I can apparently get a new wc and then do an
> update in there with no trouble. I can also update to 4110, and then
> move forward to head with no trouble.
>
> So I think something must be wrong in that wc. I didn't change
> anything by hand, so possibly it's a svn bug that got it to this
> state.
Probably.
Working on issue #689 as fast as can... :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Thu, Dec 19, 2002 at 10:09:34AM +1100, Martin Pool wrote:
> On 18 Dec 2002, Michael Wood <mw...@its.uct.ac.za> wrote:
>
> > Sorry, I wasn't clear and hadn't checked your attached packet capture
> > yet. In my case the response WAS gzipped twice. I see yours wasn't.
> > Maybe it's a different bug?
>
> I'm sorry to contradict you, but it looks like your capture is in fact
> only gzipped once.
[snip]
OK, never mind then :) I obviously did something stupid.
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Martin Pool <mb...@samba.org>.
On 18 Dec 2002, Michael Wood <mw...@its.uct.ac.za> wrote:
> Sorry, I wasn't clear and hadn't checked your attached packet capture
> yet. In my case the response WAS gzipped twice. I see yours wasn't.
> Maybe it's a different bug?
I'm sorry to contradict you, but it looks like your capture is in fact
only gzipped once.
Here's what I'm doing:
I save the attachment from your mail, bunzip2 it to get a plain
capture file. Open that in Ethereal. Scroll down to the HTTP
response starting in packet 99. Right click and choose 'Follow HTTP
Stream'. The headers are
HTTP/1.0 200 OK
Date: Wed, 18 Dec 2002 06:32:02 GMT
Server: Apache/2.0.44-dev (Unix) mod_ssl/2.0.44-dev OpenSSL/0.9.6 DAV/2 SVN/0.14.5 (dev build)
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Type: text/xml; charset="utf-8"
X-Pad: avoid browser bug
X-Cache: MISS from cache22.uct.ac.za
X-Cache-Lookup: MISS from cache22.uct.ac.za:8080
Proxy-Connection: close
Choose 'marmite->cache22' from the direction dropdown. Choose "Save
as". Open the file in emacs, select the response body, and pipe it
through zcat. The output is XML.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Michael Wood <mw...@its.uct.ac.za>.
Hi
On Wed, Dec 18, 2002 at 06:33:45PM +1100, Martin Pool wrote:
> On 18 Dec 2002, Michael Wood <mw...@its.uct.ac.za> wrote:
>
[snip]
> > Note the double "Accept-Encoding: gzip"
> >
> > The response is gzipped twice!
>
> Yes, I have that header too. I agree it is redundant, which is
> perhaps a slight neon bug.
>
> However I don't think server would interpret it as a request to gzip
> the response body twice -- that's not what it means in HTTP, and it's
> hard to believe the server would even be structured to do it if it
> wanted.
>
> And in fact at least in my capture the response is singly-gzipped
> XML.
Sorry, I wasn't clear and hadn't checked your attached packet capture
yet. In my case the response WAS gzipped twice. I see yours wasn't.
Maybe it's a different bug?
hmmm... now I see svn.collab.net's not resolving again.
Anyway, I've attached my packet capture.
--
Michael Wood <mw...@its.uct.ac.za>
Re: bug? "Delta source ended unexpectedly"
Posted by Martin Pool <mb...@samba.org>.
On 18 Dec 2002, Michael Wood <mw...@its.uct.ac.za> wrote:
> I got the same thing this morning. I also got a packet capture and
> found this in the request:
>
> REPORT http://svn.collab.net/repos/svn/trunk HTTP/1.1
> Host: svn.collab.net
> User-Agent: neon/0.23.3 SVN/0.14.2 (dev build)
> Connection: TE
> TE: trailers
> Content-Length: 20994
> Content-Type: text/xml
> Accept-Encoding: gzip
> Accept-Encoding: gzip
>
> [...]
>
> Note the double "Accept-Encoding: gzip"
>
> The response is gzipped twice!
Yes, I have that header too. I agree it is redundant, which is
perhaps a slight neon bug.
However I don't think server would interpret it as a request to gzip
the response body twice -- that's not what it means in HTTP, and it's
hard to believe the server would even be structured to do it if it
wanted.
And in fact at least in my capture the response is singly-gzipped
XML.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Philip Martin <ph...@codematters.co.uk>.
Martin Pool <mb...@samba.org> writes:
> > 3. Karl is working on getting checksums moving back and forth between
> > client and server, so that if this happens again, you'll get a big
> > fat checksum error, rather than a working file with weird data.
>
> Suppose I had made a lot of changes in that wc, and I was updating
> preparatory to committing. After this bug occurs, I have a dead wc
> containing all my work. Even if the files weren't corrupted, being
> stuck in this state is very bad. I suppose the only way to recover is
> to diff and merge by hand into a fresh checkout.
That's incorrect, as I understand it. The checksum will simply
identify that the working copy text-base doesn't match the text of the
version-url item in the repository. The fix remains the same, remove
the wcprop cache thus causing it to be regenerated. Having done this
the checksum should match.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Martin Pool <mb...@samba.org>.
On 18 Dec 2002, Ben Collins-Sussman <su...@collab.net> wrote:
> 1. the immediate solution is to just cd into .svn/wcprops in the
> offending directory, and delete everything. The caches will be
> rebuilt as necessary.
Perhaps there should be a "svn cleanup --flush-cache"?
Of course this bug ought to be fixed properly, but it's possible there
will be others related to incorrect caches in the future. Having an
official way to clean all client side caches might give people a way
to get up and running again, and knowing that flushing the caches
fixed it might make the bug report more useful. (Of course, it would
also destroy possible interesting information about the bug... hm.)
Just an idea.
> 2. If you're really paranoid, you can simply checkout a whole new
> working copy with today's latest svn client. (I did that a few
> weeks ago, and I've not had any problems updating anything.)
>
> 3. Karl is working on getting checksums moving back and forth between
> client and server, so that if this happens again, you'll get a big
> fat checksum error, rather than a working file with weird data.
Suppose I had made a lot of changes in that wc, and I was updating
preparatory to committing. After this bug occurs, I have a dead wc
containing all my work. Even if the files weren't corrupted, being
stuck in this state is very bad. I suppose the only way to recover is
to diff and merge by hand into a fresh checkout.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by mark benedetto king <bk...@answerfriend.com>.
On Wed, Dec 18, 2002 at 07:43:42AM -0600, Ben Collins-Sussman wrote:
> How it goes wrong: we've had some bugs in the past whereby 'svn
> switch' hasn't properly rewritten (or deleted) the caches. Obviously,
> this problem can come back and bite you months later: ra_dav ends up
> asking for a diff against a file that you don't have.
>
While that might certainly be a source of simmilar problems, I'm not
sure it's the cause in this case.
There's been a rash of these problems. All centered around
/tools/hook-scripts/propchange-email.pl, IIRC.
jerenkrantz, hadaka, several others, and I have all seen this
problem, and (I think), all on this one file. I'll hazard a guess
that not all of us have run "svn switch" on it.
I raise this point because I don't want to dismiss what could
be a more subtle mod_dav_svn problem as a "known issue".
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> > And now it happens consistently when I type 'svn up'.
> >
> > So, if there's something someone wants me to do, just holler.
>
> Try to narrow down where the problem is. Can you 'svn up' the
> 'tools' directory? Or the 'tools/cvs2svn' directory? If you can,
> find a single file that fails in this fashion.
>
> Then, post two things to the list:
>
> (1) `svn st -v file_that_wont_update`
> (2) The contents of ".svn/wcprops/file_that_wont_update.svn-work"
Karl is right, though: many people have seen failed updates before
("delta source ended unexpectedly", or worse... a munged working
file). The reason has *always* been because of a messed up wcprop
cache. It's becoming a FAQ at this point.
How it works: when you checkout a file, ra_dav stores a url cache
which uniquely identifies the created-rev/path pair. Later, when you
update the file, ra_dav asks mod_dav_svn for a binary diff against
that specific cached url.
Why we have it: caching the unique url saves a couple of network
round trips. If not present, it's rederived anyway.
How it goes wrong: we've had some bugs in the past whereby 'svn
switch' hasn't properly rewritten (or deleted) the caches. Obviously,
this problem can come back and bite you months later: ra_dav ends up
asking for a diff against a file that you don't have.
The solutions:
1. the immediate solution is to just cd into .svn/wcprops in the
offending directory, and delete everything. The caches will be
rebuilt as necessary.
2. If you're really paranoid, you can simply checkout a whole new
working copy with today's latest svn client. (I did that a few
weeks ago, and I've not had any problems updating anything.)
3. Karl is working on getting checksums moving back and forth between
client and server, so that if this happens again, you'll get a big
fat checksum error, rather than a working file with weird data.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > So what on earth do you actually have? A copy of propchange-email.pl
> > or commit-email.pl?
>
> Oh crap, this is some nasty thing!
And apparently not universal. I did the same thing to two different
working copies (one that hadn't been updated in about a month, one
much more recently). No problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> > Ben and I have independently determined the same thing. Philip, would
> > you be so kind as to file a P1 issue?
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1045
Bee-oo-tiful. Thanks, Philip!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Philip Martin <ph...@codematters.co.uk>.
cmpilato@collab.net writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > Now I don't pretend to understand all this HTTP/DAV stuff but by
> > switching on neon HTTP debugging it appears to be a server problem,
> > not a client one.
>
> Ben and I have independently determined the same thing. Philip, would
> you be so kind as to file a P1 issue?
http://subversion.tigris.org/issues/show_bug.cgi?id=1045
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by cm...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Now I don't pretend to understand all this HTTP/DAV stuff but by
> switching on neon HTTP debugging it appears to be a server problem,
> not a client one.
Ben and I have independently determined the same thing. Philip, would
you be so kind as to file a P1 issue?
---------------------------------------------------------------------
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: 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 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: 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
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 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: bug? "Delta source ended unexpectedly"
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > Can anyone else reproduce besides me?
>
> $ mv hook-scripts/ hook-scripts-keep
> $ svn up
> A hook-scripts
> A hook-scripts/commit-access-control.pl
> A hook-scripts/mailer.py
> A hook-scripts/svnperms.py
> A hook-scripts/propchange-email.pl
> A hook-scripts/commit-email.pl
> A hook-scripts/mailer.conf.example
> A hook-scripts/svnperms.conf.example
> A hook-scripts/README
> A hook-scripts/commit-access-control.cfg.example
> Updated to revision 4156.
> $ cat hook-scripts/.svn/wcprops/propchange-email.pl.svn-work
> K 25
> svn:wc:ra_dav:version-url
> V 65
> /repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
> END
>
> That's broken :-(
Now I don't pretend to understand all this HTTP/DAV stuff but by
switching on neon HTTP debugging it appears to be a server problem,
not a client one. The client does
GET /repos/svn/!svn/ver/4111/trunk/tools/hook-scripts/propchange-email.pl
and gets the body of the file, and then the client does
PROPFIND /repos/svn/!svn/ver/4111/trunk/tools/hook-scripts/propchange-email.pl
and in response the servers sends
[status-line] < HTTP/1.1 207 Multi-Status
[hdr] Date: Wed, 18 Dec 2002 19:20:04 GMT
Header Name: [date], Value: [Wed, 18 Dec 2002 19:20:04 GMT]
[hdr] Server: Apache/2.0.44-dev (Unix) mod_ssl/2.0.44-dev OpenSSL/0.9.6 DAV/2 SV
N/0.14.5 (dev build)
Header Name: [server], Value: [Apache/2.0.44-dev (Unix) mod_ssl/2.0.44-dev OpenS
SL/0.9.6 DAV/2 SVN/0.14.5 (dev build)]
[hdr] Content-Length: 1253
Header Name: [content-length], Value: [1253]
[hdr] Content-Type: text/xml; charset="utf-8"
Header Name: [content-type], Value: [text/xml; charset="utf-8"]
[hdr]
End of headers.
Reading 1253 bytes of response body.
Got 1223 bytes.
Read block (1223 bytes):
[<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:S="svn:" xmlns:C="svn:custom:" xmlns:lp4="svn:" xmlns:lp1="DAV
:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:lp2="http://apache.
org/dav/props/">
<D:href>/repos/svn/!svn/bln/4111</D:href>
<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>
<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>
<lp1:resourcetype/>
<lp1:getcontentlength>14131</lp1:getcontentlength>
<lp1:getcontenttype>text/plain</lp1:getcontenttype>
<lp1:getetag>"4111//trunk/tools/hook-scripts/propchange-email.pl"</lp1:getetag>
<lp1:creationdate>2002-12-13T01:28:02.344831Z</lp1:creationdate>
<lp1:getlastmodified>Fri, 13 Dec 2002 01:28:02 GMT</lp1:getlastmodified>
<lp1:version-name>4111</lp1:version-name>
<lp1:creator-displayname>blair</lp1:creator-displayname>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<]
Note the server response includes a version-url of
/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Can anyone else reproduce besides me?
$ mv hook-scripts/ hook-scripts-keep
$ svn up
A hook-scripts
A hook-scripts/commit-access-control.pl
A hook-scripts/mailer.py
A hook-scripts/svnperms.py
A hook-scripts/propchange-email.pl
A hook-scripts/commit-email.pl
A hook-scripts/mailer.conf.example
A hook-scripts/svnperms.conf.example
A hook-scripts/README
A hook-scripts/commit-access-control.cfg.example
Updated to revision 4156.
$ cat hook-scripts/.svn/wcprops/propchange-email.pl.svn-work
K 25
svn:wc:ra_dav:version-url
V 65
/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
END
That's broken :-(
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Jani Averbach <ja...@cc.jyu.fi>.
On 18 Dec 2002, Ben Collins-Sussman wrote:
>
> Can anyone else reproduce besides me?
>
Same here, with svn-3575 and svn-4110, if that helps.
[21:54:30] ~/data/svn_stuff/svn/trunk/tools
jaa @ eowyn 46 $ svn up
A hook-scripts
A hook-scripts/commit-access-control.pl
A hook-scripts/mailer.py
A hook-scripts/svnperms.py
A hook-scripts/propchange-email.pl
A hook-scripts/commit-email.pl
A hook-scripts/mailer.conf.example
A hook-scripts/svnperms.conf.example
A hook-scripts/README
A hook-scripts/commit-access-control.cfg.example
Updated to revision 4156.
[21:55:12] ~/data/svn_stuff/svn/trunk/tools
jaa @ eowyn 47 $ cd hook-scripts/
[21:55:14] ~/data/svn_stuff/svn/trunk/tools/hook-scripts
jaa @ eowyn 48 $ svn st -v
4156 4111 blair .
4156 3768 blair README
4156 3434 kfogel commit-access-control.cfg.example
4156 3748 cmpilato commit-access-control.pl
4156 4111 blair commit-email.pl
4156 3434 kfogel mailer.conf.example
4156 3224 gstein mailer.py
4156 3765 blair propchange-email.pl
4156 3434 kfogel svnperms.conf.example
4156 4079 niemeyer svnperms.py
[21:55:19] ~/data/svn_stuff/svn/trunk/tools/hook-scripts
jaa @ eowyn 49 $ cat .svn/wcprops/propchange-email.pl.svn-work
K 25
svn:wc:ra_dav:version-url
V 65
/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
END
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> So what on earth do you actually have? A copy of propchange-email.pl
> or commit-email.pl?
Oh crap, this is some nasty thing!
My hook-scripts directory was totally normal to begin with:
$ svn st -v
[...]
4156 4111 blair propchange-email.pl
[...]
$ more .svn/wcprops/propchange-email.pl.svn-work
[...]
/repos/svn/!svn/ver/4111/trunk/tools/hook-scripts/propchange-email.pl
[...]
Then on mbk's recommendation, I ran
$ cd ..
$ rm -rf hook-scripts
$ svn up
A hook-scripts
A hook-scripts/commit-access-control.pl
A hook-scripts/mailer.py
A hook-scripts/svnperms.py
A hook-scripts/propchange-email.pl
A hook-scripts/commit-email.pl
A hook-scripts/mailer.conf.example
A hook-scripts/svnperms.conf.example
A hook-scripts/README
A hook-scripts/commit-access-control.cfg.example
Updated to revision 4156.
...and now my propchange-email.pl data is hosed in exactly the same
way everyone else's is!
$ cd hook-scripts
$ svn st -v
[...]
4156 3765 blair propchange-email.pl
[...]
$ more .svn/wcprops/propchange-email.pl.svn-work
[...]
/repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
[...]
Can anyone else reproduce besides me?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Ben Collins-Sussman <su...@collab.net>.
> Here's the file that won't update:
>
> ,----[ tools/hook-scripts/propchange-email.pl ]
> | $ svn st -v propchange-email.pl
> | 4092 3765 blair propchange-email.pl
> `----
>
> And here's the wcprops file:
>
> ,----[ tools/hook-scripts/.svn/wcprops/propchange-email.pl ]
> | K 25
> | svn:wc:ra_dav:version-url
> | V 65
> | /repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
> | END
> `----
There's the problem. Your wcprop cache is talking about a DIFFERENT
file than the one you have. It should be talking about
propchange-email.pl, not commit-email.pl!
Here are the revisions in which propchange-email.pl changed:
4111
4046
3755
3748
[...]
And here are the revisions in which commit-email.pl changed:
4111
3956
3765
[...]
Something is really messed up here. You have a file called
propchange-email.pl whose wcprop cache is for a different file
altogether, and whose last-changed-revision is for that other file as
well. Actually, even *that* is wrong. If you had r4092 of
commit-email.pl, the last-changed-rev sholud be 3956!
So what on earth do you actually have? A copy of propchange-email.pl
or commit-email.pl?
You can use 'svn cat -r' to fetch specific versions of files, and
compare them to your working file and text-base. Just to verify.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Nuutti Kotivuori <na...@iki.fi>.
cmpilato@collab.net wrote:
> Try to narrow down where the problem is. Can you 'svn up' the
> 'tools' directory? Or the 'tools/cvs2svn' directory? If you can,
> find a single file that fails in this fashion.
>
> Then, post two things to the list:
>
> (1) `svn st -v file_that_wont_update`
> (2) The contents of ".svn/wcprops/file_that_wont_update.svn-work"
Here's the file that won't update:
,----[ tools/hook-scripts/propchange-email.pl ]
| $ svn st -v propchange-email.pl
| 4092 3765 blair propchange-email.pl
`----
And here's the wcprops file:
,----[ tools/hook-scripts/.svn/wcprops/propchange-email.pl ]
| K 25
| svn:wc:ra_dav:version-url
| V 65
| /repos/svn/!svn/ver/3765/trunk/tools/hook-scripts/commit-email.pl
| END
`----
Do note that the wcprops file doesn't have the ".svn-work" suffix,
since this is an old working copy. Also I wish to mention that I
haven't ran 'svn switch' on this working copy, ever. It's just a plain
working copy who's mostly had updates, perhaps one commit. And yes,
it's rather old as well.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by cm...@collab.net.
Nuutti Kotivuori <na...@iki.fi> writes:
> Hey! I got it as well!
>
> And it's against the subversion main repository. And it's
> reproduceable.
>
> svn, version 0.15.0 (dev build)
> compiled Dec 3 2002, 21:48:28
>
> It happened after a whole load of files updated:
>
> ,----
> | ...
> | U tools/client-side/vc-svn.el
> | U tools/cvs2svn/cvs2svn.py
> | subversion/libsvn_delta/text_delta.c:463: (apr_err=200003, src_err=0)
> | svn: Incomplete data
> | svn: Delta source ended unexpectedly
> `----
>
> And now it happens consistently when I type 'svn up'.
>
> So, if there's something someone wants me to do, just holler.
Try to narrow down where the problem is. Can you 'svn up' the
'tools' directory? Or the 'tools/cvs2svn' directory? If you can,
find a single file that fails in this fashion.
Then, post two things to the list:
(1) `svn st -v file_that_wont_update`
(2) The contents of ".svn/wcprops/file_that_wont_update.svn-work"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Martin Pool <mb...@samba.org>.
On 18 Dec 2002, Nuutti Kotivuori <na...@iki.fi> wrote:
> Hey! I got it as well!
"Don't yell, sir. Everyone will want one."
> And it's against the subversion main repository. And it's
> reproduceable.
>
> svn, version 0.15.0 (dev build)
> compiled Dec 3 2002, 21:48:28
>
> It happened after a whole load of files updated:
>
> ,----
> | ...
> | U tools/client-side/vc-svn.el
> | U tools/cvs2svn/cvs2svn.py
> | subversion/libsvn_delta/text_delta.c:463: (apr_err=200003, src_err=0)
> | svn: Incomplete data
> | svn: Delta source ended unexpectedly
> `----
>
> And now it happens consistently when I type 'svn up'.
>
> So, if there's something someone wants me to do, just holler.
As Karl said, tar up the wc that reproduces it and put it somewhere
safe. Then perhaps get a network trace of the change.
If you don't know ethereal, you should be able to do it with
tcpdump -s 10000 -w delta-source-ended.cap 'tcp port 80'
You may need a -i option or to change the filter expression depending
on your network setup, proxies, etc.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Nuutti Kotivuori <na...@iki.fi>.
Michael Wood wrote:
> On Wed, Dec 18, 2002 at 04:50:11PM +1100, Martin Pool wrote:
>> I'm trying to update my Subversion tree using a local build
>>
>> svn, version 0.16.0 (dev build)
>> compiled Dec 13 2002, 12:32:42
>>
>> from trunk on that date.
>>
>> It dies with
>>
>> % svn up
>> svn: Incomplete data
>> svn: Delta source ended unexpectedly
>
> I got the same thing this morning.
Hey! I got it as well!
And it's against the subversion main repository. And it's
reproduceable.
svn, version 0.15.0 (dev build)
compiled Dec 3 2002, 21:48:28
It happened after a whole load of files updated:
,----
| ...
| U tools/client-side/vc-svn.el
| U tools/cvs2svn/cvs2svn.py
| subversion/libsvn_delta/text_delta.c:463: (apr_err=200003, src_err=0)
| svn: Incomplete data
| svn: Delta source ended unexpectedly
`----
And now it happens consistently when I type 'svn up'.
So, if there's something someone wants me to do, just holler.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: bug? "Delta source ended unexpectedly"
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Wed, Dec 18, 2002 at 04:50:11PM +1100, Martin Pool wrote:
> I'm trying to update my Subversion tree using a local build
>
> svn, version 0.16.0 (dev build)
> compiled Dec 13 2002, 12:32:42
>
> from trunk on that date.
>
> It dies with
>
> % svn up
> svn: Incomplete data
> svn: Delta source ended unexpectedly
I got the same thing this morning. I also got a packet capture and
found this in the request:
REPORT http://svn.collab.net/repos/svn/trunk HTTP/1.1
Host: svn.collab.net
User-Agent: neon/0.23.3 SVN/0.14.2 (dev build)
Connection: TE
TE: trailers
Content-Length: 20994
Content-Type: text/xml
Accept-Encoding: gzip
Accept-Encoding: gzip
[...]
Note the double "Accept-Encoding: gzip"
The response is gzipped twice!
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org