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

Strange consequence of a config-file error:)

From: Delbert Franz <iqdotdt_at_sonic.net>
Date: 2005-09-14 22:47:15 CEST

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.



To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 14 22:50:17 2005

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.