On 2007-06-17 00:52-0700 Karl Fogel wrote:
> "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> writes:
>> I have attached such a simple test bash script.
>> Here are the results on my Debian sarge system:
>>
>> [...]
>>
>> Committed revision 3.
>> 1 irwin Jun 16 19:38 branches/
>> 3 irwin Jun 16 19:38 tags/
>> 3 irwin Jun 16 19:38 tags/mytag/
>> 2 irwin Jun 16 19:38 trunk/
>> 2 irwin 22 Jun 16 19:38 trunk/test_file
>>
>> You will have to look at the script for details, but basically I created
>> a simple example of a "downgrade" that would automatically delete test_file
>> from the local working copy, then svn copied
>> to a tag directory, then svn listed the entire repo. However, you can see
>> from the above result that test_file is not in mytag so there is
>> no bug in the case when the client and server use the same system and/or
>> the file:/// access method is used!
>>
>> Are you in a position to modify the script to use the https access method?
>> The preferable test is old svn client and latest svn server. For that
>> case, the bug could be in the old client, new server, or in the apache module
>> that implements the https access method.
>
> I've tested with a modified version of your script over http://,
> svn://, and file://, and can't reproduce the bug (using latest dev
> Subversion). In all cases, test_file appears only in trunk/.
>
> Maybe there's some small chance that https:// could cause it, but I
> consider that highly unlikely. Whatever you're observing is almost
> certainly a client-side problem in 1.1.4, as the client reports the
> working copy to the server. I don't think we've ever had a bug where
> the RA layer in use changed the client's report in such a dramatic
> way.
Karl, I was glad I sent my post with my attached script both to you and the
list. The list one bounced because of some "security" rule which does not
allow bash scripts as attachments to the subversion list! So that means
nobody but you saw my script or message, but that is fine; you quoted most
of my message in any case, and they can use your more sophisticated script
if they want to test this out for themselves.
Anyway, thanks for doing some more extensive checking trying to replicate
the bug I discovered.
To summarize your results and mine, the bug appears to only occur for the
combination of old client and new https server. The old-old or new-new
combination doesn't seem to trigger it. So my best guess is something is
being lost in translation as the apache module tries to transform from old
client commands to new server commands when the svn copy WORKING_COPY URL is
being executed. IOW, my guess is it is a backwards compatibility issue with
the apache module that handles subversion.
If that is the case (or your alternative hypothesis that there is something
wrong with the old client even though it performs well when using the file
access method), then this probably isn't worth pursuing further. The number
of Debian oldstable systems is presumably rapidly shrinking, and I, for
example, will be upgrading to Debian stable or even testing later this summer
once I have finished my current research project.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 17 16:40:48 2007