You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Delbert Franz <iq...@sonic.net> on 2005/09/14 20:47:15 UTC

Strange consequence of a config-file error:)

This may not be a bug but it took more than an hour to figure out
what was wrong.  It was, in brief, the consequence of having an 
erroneous auto-props line in my config file.  I wanted to add
a library with extension .lib, under W2K, to version control. 
The erroneous line in the config file, under [auto-props], was 
(when I finally noticed it):

*.lib = mime-type:application/octet-stream

Apparently in a senior moment, I failed to say

*.lib = svn:mime-type:application/octet-stream

which was correct. 

With the erroneous config file active, I did 

svn add dsslf95.lib

and it came back with what looked OK, telling me 
about its mime-type. In retrospect, I did not notice
that there were two lines of info given:), when there
should have been only one.

The next command 

svn commit -m "Add dssfl95.lib"

Failed with the message "At least one property change failed".

This was strange.  I then disabled the erroneous 
auto-props line in the config file and did 

svn rm --force dssfl95.lib 

to remove the file from version control and from 
the directory.  I then recreated the file and 
added it again with a commit that again failed 
the same way it did earlier.  

I then copied the file with the OS copy command to 
another working copy of other related software. 
I then was able to add dsslf95.lib and commit it
with no problems.  This was strange.  No matter what
I did I could not get dssfl95.lib to add and commit
in its original directory.  Even a reboot of W2K with
the corrected config file did not fix the problem. 

I then stooped to some low cunning.  I looked in the .svn
directory and listed the entries file.  dssfl95.lib did not appear
since I had removed it from version control.  That was OK.
I then looked in the .svn/props dir and there was a file
for dssfl95.lib even though I had removed it from version 
control in the working copy.  The contents of this file,
dssfl95.lib.svn-work, contained two property definitions,
my erroneous one and the one I wanted.  
When I deleted the erroneous one (yes I know I'm not supposed
to do that), I could add and commit dssfl95.lib in its
original directory.  

Apparently svn used the file, dssfl95.lib.svn-work to set
the properties whenever I added that file.  The first time I added
dssfl95.lib to version control, .svn/props/dssfl95.lib.svn-work
was created with two properties and not one.  No hook script
existed on the server for the new property and the new property
did not have a value given either.  So far OK in my eyes.  Its 
a good thing that the commit failed:)  However, the persistence
of dssfl95.lib.svn-work once the parent file was removed from
version control caused all the subsequent failures.  If this is 
not a bug it is at least an unexpected behavior.  As always there
could well be a good explanation for this but it certainly had
me struggling for a while.   

My client is version 1.2.1 running under Win2k and the 
server is version 1.2.1 running under Linux.  I am back in 
action but if this is a bug perhaps it should be added to 
the list. 

                               Delbert


 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org