Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags

On 2007-06-16 18:09-0700 Karl Fogel wrote:

> "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> writes:
>> Is this just an uninteresting (but nasty) bug in my Debian oldstable (sarge)
>> version of subversion client (version 1.1.4-2), have I done something wrong
>> above, or do you expect "svn copy WORKING_DIRECTORY URL" to resurrect files
>> in the created tag that have been automatically deleted by the svn "updates"
>> in the working directory?
>
> The behavior you describe is definitely a bug....
>
> In fact, if you can script a recipe with your current Subversion
> client, demonstrating the bug, someone else could try to reproduce it
> on a newer version, without you having to install the newer version.
> The important thing is that the script stand alone -- it should create
> the repository itself, commit all the changes needed, etc.

Thanks for that excellent suggestion.

I have attached such a simple test bash script.

Here are the results on my Debian sarge system:

irwin@chickadee> ./test_subversion.sh
Adding /tmp/test_import/trunk
Adding /tmp/test_import/branches
Adding /tmp/test_import/tags

Committed revision 1.
Checked out revision 1.
A test_file
Adding test_file
Transmitting file data .
Committed revision 2.
D test_file
Updated to revision 1.

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.

Of course, the definitive test could be done by modifying the script for SF,
but I am reluctant to mess up my repository there any further by adding a
bunch of test crap to it, and the mess I have created by hand there at the
moment for my v2_1_0 tag is already essentially what would be generated by
this (suggested) modified script in any case.

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