Hi Pavel,
On 6/1/2016 18:04, Pavel Lyalyakin wrote:
> Hello Stefan,
>
> On Sun, May 29, 2016 at 11:03 PM, Stefan <luke1410_at_posteo.de> wrote:
>> I'm not 100% sure, but this might be related to issue #4364, which is fixed
>> in SVN 1.8.8:
>> lock of deleted pathes magically reappear when pathes are reused
>>
>> In this case upgrading to a later SVN version should resolve the issue.
>>
>> Alternatively the issue at question might also be #2507 which is not yet
>> resolved:
>> 'commit --no-unlock' doesn't remove locks on files deleted
>>
>> In this case the workaround might be to ensure in the tools to not use the
>> --no-unlock flag and/or to ensure that for deleted files the lock is removed
>> first via svn unlock.
> How did you determine that this is #4364 or #2507?
thanks for asking and sorry for the late response (quite some busy days
at work and in private, so I just got to reply right now).
Well, I came to that idea because of the given error message:
"[...] error running command [svn, unlock [...] svn: E155008: The node
'C:\SoftwareAG\IntegrationServer\packages\testsvn4444\ns\new_folder22\new_flowservice1'
is not a file"
At the time of replying there I was wondering why svn would try to
unlock new_flowservice1 which, taken from the error message, didn't seem
to be a file (but presumably a folder). Only after reading your reply I
got the idea that I incorrectly assumed the unlock call was some
implicit action from some svn-API call where svn would try to perform an
invalid unlock rather than some explicit svn command line call from the
3rd party tool/script. Anyway, to answer your question:
The fact that Divvela stated that the external vendor they contacted
said it's an issue in Subversion, I assumed the vendor was aware of a
known bug in Subversion and I tried to find out which one they might
refer to (aka: whether an upgrade to a later version would help the user
or whether there's a workaround for an unresolved issue).
Searching SVN's issue tracker for "unlock" and issues not yet resolved
(or resolved after 1.7.9) brought up these two candidates for me.
SVN-4364 is reported to affect 1.7.x and was fixed in 1.8.8. Therefore
the version range would match.
The comments depict a repro case of a locked file being removed and the
lock not being dropped from the db. After recreating a file with the
same path, the new file was locked. It's stated that the corresponding
entry in the sqlite db didn't get the lock entry removed. So I assumed
it could also be a possible variation to end up with a lock entry in the
db on a directory, if instead of creating a file on that path, one would
create a directory and that could then trigger SVN to try to unlock the
directory (aka: this was due to my false assumption of an implicit
rather than an explicit unlock action - see above).
For SVN-2507 my thinking was that if a commit was done with the
--no-unlock option it would also lead to the dangling lock entry in the
sqlite db. Again, assuming that creating a folder with the same name
afterwards would then result in a folder with an associated lock entry
in the db, that sounded like a possible cause of the reported error and
therefore another candidate of what that 3rd-party vendor might have
been referring to (again: all under the same wrong explicit/implicit
unlock assumption).
> To me it looks like webmethods is calling some Subversion client and it
> is trying to perform `svn unlock` operation on a folder. Looks like
> the error it totally expected in such case.
Sounds absolutely right to me, now that I get that's most likely some
explicit svn unlock command call the other tool is doing.
>
> Without some additional description of the case it's impossible to
> tell what's going on.
Regards,
Stefan
Received on 2016-06-04 00:51:44 CEST