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
Received on Wed Sep 14 22:50:17 2005