[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ghudson's 'svn st' problem he mentioned on IRC...

From: <kfogel_at_collab.net>
Date: 2003-12-30 20:24:40 CET

jszakmeister@comcast.net writes:
> Well, I guess it depends on what you mean about 'reproducing the bug'.
> Currently if you checkout svn from trunk/ and compare the files in the
> subversion/bindings/com with their text-base equivalents, the line
> endings are not correct. To me, that is reproducible. What boggles
> my mind is how did we get those files there in the first place (which
> is what I see is troubling you as well).

What I'm saying is, there *was* a bug that caused the repository to
get into this state. That bug could be gone now (we can't seem to
stimulate it), but the bug's disappearance wouldn't magically fix up
the old bogus repository state. It would just mean no new instances
of that particular bogosity would appear.

> As long as I do a checkout have different line endings on those files
> mentioned above, I can hardly say this bug is gone. I admit there is
> a problem of finding the correct sequence to cause this issue, but
> something wrong is clearly happening.

s/clearly happening/clearly happened/

I'm not saying the bug is definitely gone now. Just saying a) we
haven't reproduced it yet, and b) there's an explanation for the
current behavior involving a past bug that need no longer exist.

> Actually, I do have a couple. I want to track down were the file is
> collected from the server is collected, and see if the text-base is
> converted correctly at that point.

That would be great!

> I realize this may be asking a lot, but it there a way I could get my
> hands on a dump of the Subversion repository? As long as the problem
> remains, you could probably get by with dumping the last few
> revisions. I'd like to use it in my testing since it's the only
> repository and associated WC that I know of that has this problem.
> Perhaps at some point we made a fundamental assumption that was wrong,
> and soemthing is assuming that the data is formatted one way, when in
> reality it might be formatted another way.

You got it, baby:



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 30 21:17:04 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.