[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: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-06-17 03:09:29 CEST

"Alan W. Irwin" <irwin@beluga.phys.uvic.ca> writes:
> Today I followed the "Creating a Complex Tag" prescription in the subversion
> book. I did a number of "svn update --revision nnn" commands in the working
> copy, and some of those "updates" deleted files which did not exist in the
> old revision. However, those same files show up in the tag that I create
> from the working copy.
> Here is what I did:
> svn copy free_eos-2.1.0 \
>> https://freeeos.svn.sourceforge.net/svnroot/freeeos/tags/v2_1_0
> Committed revision 475
> When I checked out that tag and compared it with free_eos-2.1.0 all files
> that had merely been revised by "svn update --revision nnn" commands were
> identical (aside from some $Id changes). However, files that had
> automatically been deleted in the working copy by the updates appeared in
> the fresh checkout as their HEAD revision which, of course, violates the
> rule (stated in the subversion book) that "svn copy WORKING_DIRECTORY URL"
> produces an "exact" copy of the working directory.
> 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?
> I do intend to update that version of my subversion client later this
> summer, but there did not seem to be any urgency because it has worked fine
> with the SourceForge subversion server up until this problem I discovered
> today.

The behavior you describe is definitely a bug, but with such an old
client our first advice would be (you guessed it) to upgrade and try
to reproduce the problem. If you can reproduce it (preferably with
the latest release of Subversion, or with a head-of-trunk buid), and
can script the reproduction recipe, that would be the best thing --
scripted recipes are *very* helpful in fixing bugs.

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.

(Yes, I could probably write such a script from your description
above, but I couldn't be 100% sure I'm doing exactly what needs to be
done to reproduce the bug. If you do it, then we *know* it reproduces
for you, and it's just a matter of me trying it with trunk svn...)


Subversion support & consulting  <>  http://producingoss.com/consulting.html
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 17 03:09:45 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.