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

Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags

From: Steve Bakke <steven.bakke_at_amd.com>
Date: 2007-06-18 18:55:01 CEST

We encountered a somewhat similar issue relating to delete followed by cp
from the working copy. We filed this on the subversion tracker. It has
to do with the working copy metadata of the parent directory not being
updated which then causes the 'cp' operation to fail saying that the deleted
item is missing. I'm curious whether or not these are related. It has been
marked '1.6-consider':

http://subversion.tigris.org/issues/show_bug.cgi?id=2763

-steve

On 6/16/07 11:00 PM, "Alan W. Irwin" <irwin@beluga.phys.uvic.ca> wrote:

> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 18 18:54:59 2007

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

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