You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> on 2007/06/17 00:59:14 UTC
svn copy WORKING_DIRECTORY URL gives unexpected results for tags
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.
BTW, my heartfelt thanks to the subversion developers for their excellent
work! Since 2001 I have been using CVS at SF, but I recently participated
in a project there that was using subversion, and it really opened my eyes
to what I was missing. Since then, I have changed six SF projects over from
CVS to subversion since one day of svn use makes you dislike CVS from then
on.
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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by Karl Fogel <kf...@red-bean.com>.
"Alan W. Irwin" <ir...@beluga.phys.uvic.ca> writes:
> 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.
Well, you know you can always just make a copy of trunk, restricting
all your testing to some throwaway branch under /branches/... it
doesn't have to "mess up" anything, really.
(I'm working with your script now, but no need for us to wait on each
other.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tagsi
Posted by "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>.
On 2007-06-17 12:50-0400 Mark Phippard wrote:
> On 6/17/07, Karl Fogel <kf...@red-bean.com> wrote:
>> "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> writes:
>> > 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.
>>
>> Hmmm, that's not good -- a lot of people need to send script
>> attachments here. Can you forward me that bounce message personally,
>> and I'll contact the tigris.org people and see if they can do anything
>> about the setting?
>
> His message came through fine. See:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=67189
>
I am pleased that shell script attachments are not shut out of this list,
and I agree the bounce messages I received (now I have two) must be from
users of the list, instead. Sorry for the noise about this.
I am going to unsubscribe now until I have more subversion questions.
Thanks, Karl, for your help/advice with my original question.
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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by Mark Phippard <ma...@gmail.com>.
On 6/17/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> writes:
> > 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.
>
> Hmmm, that's not good -- a lot of people need to send script
> attachments here. Can you forward me that bounce message personally,
> and I'll contact the tigris.org people and see if they can do anything
> about the setting?
His message came through fine. See:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=67189
He probably got a bounce from some individual that could not receive it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by Karl Fogel <kf...@red-bean.com>.
"Alan W. Irwin" <ir...@beluga.phys.uvic.ca> writes:
> 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.
Hmmm, that's not good -- a lot of people need to send script
attachments here. Can you forward me that bounce message personally,
and I'll contact the tigris.org people and see if they can do anything
about the setting?
Thanks,
-Karl
--
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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>.
On 2007-06-17 00:52-0700 Karl Fogel wrote:
> "Alan W. Irwin" <ir...@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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by Karl Fogel <kf...@red-bean.com>.
"Alan W. Irwin" <ir...@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.
Here's the script I used, basically yours with some modifications for
portability and convenience:
--------------------8-<-------cut-here---------8-<-----------------------
#!/bin/bash
# Which Subversion binaries to use -- by default, development versions.
BIN_PREFIX=/home/kfogel/src/subversion
SVN=${BIN_PREFIX}/subversion/svn/svn
SVNSERVE=${BIN_PREFIX}/subversion/svnserve/svnserve
SVNADMIN=${BIN_PREFIX}/subversion/svnadmin/svnadmin
# Choose one of these three access methods by {un}commenting.
# In the http:// case, you'll also need to set up something in
# httpd.conf, for example:
#
# <Location /repro>
# DAV svn
# SVNParentPath /home/kfogel/src/repro-dir
# </Location>
#
# URL=http://localhost/repro/repos
URL=svn://localhost/repos
# URL=file:///`pwd`/repos
###########################################################
### You shouldn't have to change anything below here. ###
###########################################################
# Clean up all created directories:
rm -rf import-me repos wc
# Create import tree
mkdir -p import-me/branches import-me/tags import-me/trunk
# Start svnserve
${SVNSERVE} --pid-file svnserve-pid -d -r `pwd`
# Create repository, give svnserve r/w access.
${SVNADMIN} create repos
echo "[general]" > repos/conf/svnserve.conf
echo "anon-access = write" >> repos/conf/svnserve.conf
echo "auth-access = write" >> repos/conf/svnserve.conf
# Populate the repository.
${SVN} import import-me ${URL} -m "initial import"
# Create local working copy of empty tree (revision 1);
# create test file in trunk for revision 2
# update to empty tree (revision 1)
${SVN} checkout ${URL}/trunk wc
cd wc
echo "contents of test file" > test_file
${SVN} add test_file
${SVN} commit -m "commit test file" test_file
${SVN} update --revision 1
cd ..
# copy that result to repository tag, then list the repository
${SVN} copy -m "create mytag" wc ${URL}/tags/mytag
${SVN} list --verbose --recursive ${URL}
# Shut down svnserve.
kill -9 `cat svnserve-pid`
--------------------8-<-------cut-here---------8-<-----------------------
Best,
-Karl
--
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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for
tags
Posted by Steve Bakke <st...@amd.com>.
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" <ir...@beluga.phys.uvic.ca> wrote:
> On 2007-06-16 18:09-0700 Karl Fogel wrote:
>
>> "Alan W. Irwin" <ir...@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
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>.
On 2007-06-16 18:09-0700 Karl Fogel wrote:
> "Alan W. Irwin" <ir...@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
__________________________
Re: svn copy WORKING_DIRECTORY URL gives unexpected results for tags
Posted by Karl Fogel <kf...@red-bean.com>.
"Alan W. Irwin" <ir...@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...)
Best,
-Karl
--
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