Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#2838 closed defect (fixed)

SVNPoller failes after upgrade to SVN 1.8.9

Reported by: materialdreams Owned by:
Priority: major Milestone: 0.9.0
Version: 0.8.6p1 Keywords: SVNPoller
Cc:

Description (last modified by dustin)

I needed to upgrade the SVN client to 1.8.9 on the buildmaster and now the SVNPoller reports the following error:

File "/usr/local/lib/python2.6/dist-packages/Twisted-12.2.0-py2.6-linux-i686.egg/twisted/internet/defer.py", line 464, in _startRunCallbacks
            self._runCallbacks()
        --- <exception caught here> ---
          File "/usr/local/lib/python2.6/dist-packages/Twisted-12.2.0-py2.6-linux-i686.egg/twisted/internet/defer.py", line 551, in _runCallbacks
            current.result = callback(current.result, *args, **kw)
          File "/usr/local/lib/python2.6/dist-packages/buildbot-0.8.6p1-py2.6.egg/buildbot/changes/svnpoller.py", line 196, in determine_prefix
            (self.svnurl, root))
        exceptions.AssertionError: svnurl='https://QLTFS02.qualiant.at:8443/svn/JOB/ljs_app' doesn't start with <root>='https://qltfs02.qualiant.at:8443/svn/JOB'

I've traced the output of the actual svn info command and it is as follows:

<info>
<entry kind="dir" path="ljs_app" revision="43372">
<url>https://qltfs02.qualiant.at:8443/svn/JOB/ljs_app</url>
<relative-url>^/ljs_app</relative-url>
<repository>
<root>https://qltfs02.qualiant.at:8443/svn/JOB</root>
<uuid>a9304175-a405-0a43-ac01-657dd0c039f0</uuid>
</repository>
<commit revision="43372">
<author>doberkofler</author>
<date>2014-07-18T06:29:01.631957Z</date>
</commit>
</entry>
</info>

There seems to be a <root> element but i guess the problem is more complex and I would really need some help to get this problem solved.

thank you!

Attachments (1)

twistd.log (4.1 KB) - added by materialdreams 5 years ago.

Download all attachments as: .zip

Change History (10)

Changed 5 years ago by materialdreams

comment:1 Changed 5 years ago by dustin

  • Description modified (diff)
  • Milestone changed from undecided to 0.9.0
  • Priority changed from blocker to critical

comment:2 Changed 5 years ago by dustin

  • Description modified (diff)

comment:3 follow-up: Changed 5 years ago by sa2ajj

.startswith (which is used in the above check) is case sensitive. The URL given to SVNPoller uses upper case, while the root returned by server is in lower case (probably, it's how the svn server determines its own hostname).

Can you try to give the URL in all lower case letters?

comment:4 Changed 5 years ago by dustin

Nice find - thanks!

The <root> in the error message is confusing, sending you looking for an XML element. I'll fix the error message to be (much) clearer.

comment:5 in reply to: ↑ 3 Changed 5 years ago by materialdreams

Replying to sa2ajj:

.startswith (which is used in the above check) is case sensitive. The URL given to SVNPoller uses upper case, while the root returned by server is in lower case (probably, it's how the svn server determines its own hostname).

Can you try to give the URL in all lower case letters?

You are absolutely right! I just didn't see it but I guess the compare should rather be case insensitive anyway. I change the URL to lower case and it worked as before. Thank you very much!

Last edited 5 years ago by materialdreams (previous) (diff)

comment:6 Changed 5 years ago by sa2ajj

Side note: only protocol and host part can be compared w/o regard to the case. The rest of the URL must be compared in case sensitive way.

comment:7 Changed 5 years ago by dustin

  • Priority changed from critical to major
  • Resolution set to fixed
  • Status changed from new to closed

Right, the fuller solution here would be to canonicalize the URL. We have svnUriCanonicalize in the SVN source step -- maybe that could be moved to a utility module and used from both?

At any rate, the error message is fixed in [b9eea1fc0d5d2c3f8f5db28b11c3a616d32ccc4f], so I'll call the bug fixed, but a patch to use svnUriCanoincalize would be great.

comment:8 Changed 5 years ago by sa2ajj

Related question: what would be the right location for this utility function? buildbot.util does not seem to be the right place.

Should a new hierarchy be created, like buildbot.support?

comment:9 Changed 5 years ago by dustin

I think buildbot.util.svn would be a good module path for it. We use util pretty broadly for self-contained functions or classes that are, or may be, used by more than one part of Buildbot.

Note: See TracTickets for help on using tickets.