• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      Having WebSVN 2.2 set up, I have encountered a problem where the URL generated
      using "http://server/websvn/filedetails.php/?repname=MyRepo&path=
      " as baseURL in the configuration for file "/trunk/src/Foo.java" resulted in

      "http://server/websvn/filedetails.php/trunk/src/Foo.java?repname=MyRepo&path="
      but expected
      "http://server/websvn/filedetails.php?repname=MyRepo&path=/trunk/src/Foo.java"

      The file path should appear at the end of the baseURL.

          [JENKINS-3481] Incorrect WebSVN path generation

          Jason Chaffee added a comment -

          Are other SCM browsers integrated with the SCM plugin itself? I have looked at the Hudson code in
          awhile, so I am not sure on the state of things, but I am not sure why WebSVN or ViewVC, etc. would be
          part of the SCM code itself? For example, I know the sventon (sp) SVN browser is in a plugin.

          From my perspective, it is a seperation of concerns. Because WebSVN isn't Subversion and Subversion
          does not include in WebSVN, but rather WebSVN is an application that sits on top of Subversion.

          Just playing devil's advocate here. I do not have strong feelings on this one.

          Jason Chaffee added a comment - Are other SCM browsers integrated with the SCM plugin itself? I have looked at the Hudson code in awhile, so I am not sure on the state of things, but I am not sure why WebSVN or ViewVC, etc. would be part of the SCM code itself? For example, I know the sventon (sp) SVN browser is in a plugin. From my perspective, it is a seperation of concerns. Because WebSVN isn't Subversion and Subversion does not include in WebSVN, but rather WebSVN is an application that sits on top of Subversion. Just playing devil's advocate here. I do not have strong feelings on this one.

          frohman added a comment -

          Adding myself to CC

          frohman added a comment - Adding myself to CC

          Yes, many of them, do. Subversion plugin has 5 or 6 repository browser
          implementations built-in.

          The justification is that the repository browser occupies a very small UI
          surface until they are enabled, hence having them around doesn't hurt the users
          too much.

          Kohsuke Kawaguchi added a comment - Yes, many of them, do. Subversion plugin has 5 or 6 repository browser implementations built-in. The justification is that the repository browser occupies a very small UI surface until they are enabled, hence having them around doesn't hurt the users too much.

          Jason Chaffee added a comment -

          Fair enough.

          BTW, my original comment was about moving it out of core into a plugin and I wasn't aware that it had
          already been done by moving subversion into a plugin putting WebSVN in the subversion plugin.

          I just thought of one more reason why it might make sense to keep Subversion and the browsers in a
          different plugins and this is because each user may want to use a different version of a particular
          browser, especially if it is not possible to maintain the same URL for the different versions. There
          might need to be a 1.0 version and a 2.0 version because browser URL mappings may need to be
          different. This logic could be handled in the Subversion plugin, but it would require a little bit of logic.
          Again I am just playing devil's advocate for sake of discussion to make sure the best decision is made
          as I am not as familiar with the state of the Hudson code as I was when I first created the WebSVN
          patch.

          Jason Chaffee added a comment - Fair enough. BTW, my original comment was about moving it out of core into a plugin and I wasn't aware that it had already been done by moving subversion into a plugin putting WebSVN in the subversion plugin. I just thought of one more reason why it might make sense to keep Subversion and the browsers in a different plugins and this is because each user may want to use a different version of a particular browser, especially if it is not possible to maintain the same URL for the different versions. There might need to be a 1.0 version and a 2.0 version because browser URL mappings may need to be different. This logic could be handled in the Subversion plugin, but it would require a little bit of logic. Again I am just playing devil's advocate for sake of discussion to make sure the best decision is made as I am not as familiar with the state of the Hudson code as I was when I first created the WebSVN patch.

          If you prefer to move it to a separate plugin, please feel free to do so.

          Kohsuke Kawaguchi added a comment - If you prefer to move it to a separate plugin, please feel free to do so.

          Jason Chaffee added a comment -

          The fact that is has already been moved to a plugin, addresses my first comment/concern about having it
          in a plugin. Other than that, I do not have strong feelings either way. I am fine with whatever you think is
          best, easiest, etc. I was merely trying to provide some "possible" reasons why it might make sense. There
          might be more compelling reasons why it might not, but I think you are the one who can make the best
          decision on this one because I haven't been in the code for several months now and I am really making
          my statements from a theoretical point of view.

          Jason Chaffee added a comment - The fact that is has already been moved to a plugin, addresses my first comment/concern about having it in a plugin. Other than that, I do not have strong feelings either way. I am fine with whatever you think is best, easiest, etc. I was merely trying to provide some "possible" reasons why it might make sense. There might be more compelling reasons why it might not, but I think you are the one who can make the best decision on this one because I haven't been in the code for several months now and I am really making my statements from a theoretical point of view.

          Code changed in hudson
          User: : andreasmandel
          Path:
          trunk/hudson/plugins/WebSVN2/pom.xml
          trunk/hudson/plugins/WebSVN2/src/main/java/hudson/plugins/websvn2/WebSVN2RepositoryBrowser.java
          trunk/hudson/plugins/WebSVN2/src/main/resources/hudson/plugins/websvn2/WebSVN2RepositoryBrowser/config.jelly
          trunk/hudson/plugins/WebSVN2/src/main/resources/index.jelly
          trunk/hudson/plugins/WebSVN2/src/main/webapp/help-url.html
          http://jenkins-ci.org/commit/34760
          Log:
          Initial revision of WebSVN2 plugin addressing JENKINS-3481, JENKINS-5060

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : andreasmandel Path: trunk/hudson/plugins/WebSVN2/pom.xml trunk/hudson/plugins/WebSVN2/src/main/java/hudson/plugins/websvn2/WebSVN2RepositoryBrowser.java trunk/hudson/plugins/WebSVN2/src/main/resources/hudson/plugins/websvn2/WebSVN2RepositoryBrowser/config.jelly trunk/hudson/plugins/WebSVN2/src/main/resources/index.jelly trunk/hudson/plugins/WebSVN2/src/main/webapp/help-url.html http://jenkins-ci.org/commit/34760 Log: Initial revision of WebSVN2 plugin addressing JENKINS-3481 , JENKINS-5060

          The WebSVN2 plugin should work fine with current WebSVN.

          Andreas Mandel added a comment - The WebSVN2 plugin should work fine with current WebSVN.

          daniel carter added a comment -

          Can we get the WebSVN browser that is included removed from the SVN plugin. It's annoying to see that WebSVn support is there and spend ages trying to fix the problem where it's appending a / to the URL and then after a few searches finding that it's a known issue and you have to install WebSVN2 to get a working version.

          It would be much easier if there was no WebSVN support in the base system and then users would check available plugins and find the working WebSVN2 plugin.

          daniel carter added a comment - Can we get the WebSVN browser that is included removed from the SVN plugin. It's annoying to see that WebSVn support is there and spend ages trying to fix the problem where it's appending a / to the URL and then after a few searches finding that it's a known issue and you have to install WebSVN2 to get a working version. It would be much easier if there was no WebSVN support in the base system and then users would check available plugins and find the working WebSVN2 plugin.

          the websvn2 plugin doesn't work with websvn 2.3.3
          We have added a version which works
          Please can you check if it works and update the plugin. Thanks WebSVN2.zip

          Thorsten Kohlhepp added a comment - the websvn2 plugin doesn't work with websvn 2.3.3 We have added a version which works Please can you check if it works and update the plugin. Thanks WebSVN2.zip

            Unassigned Unassigned
            jtong jtong
            Votes:
            6 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: