Hi Pavel, On 6/1/2016 18:04, Pavel Lyalyakin wrote: > Hello Stefan, > > On Sun, May 29, 2016 at 11:03 PM, Stefan <luke1...@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
smime.p7s
Description: S/MIME Cryptographic Signature
