Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-4154

when second svn repository isn't in workspace, hudson re-checks out first repository too instead of updating

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • None
    • Platform: All, OS: All

      Add repository A as a subversion repository for a project. Build. Now add a
      second repository, B. Hudson will say "Checking out a fresh workspace because
      ${env.workspace}/B doesn't exist", but will actually check out both A and B fresh.

      This causes the next build to take a long time after adding (or changing) a
      secondary repository and also seems superfluous; A should be updated as usual if
      it still exists, and B should be checked out.

          [JENKINS-4154] when second svn repository isn't in workspace, hudson re-checks out first repository too instead of updating

          IIUC, this is a relatively minor issue (in that it only happens when you change
          a configuration), and it still behaves correctly, it's just that it takes longer?

          Kohsuke Kawaguchi added a comment - IIUC, this is a relatively minor issue (in that it only happens when you change a configuration), and it still behaves correctly, it's just that it takes longer?

          mcrooney added a comment -

          It is true that it only occurs when changing a configuration, but it has led to
          data loss a number of times for us as it wipes out the old checkout where I had
          been doing some uncommitted work on files related to Hudson.

          When initially setting up a project, I end up changing the configuration a
          couple times, which is also the time when I'd be experimenting with local
          changes to build files and such, as I don't want to commit until I know it
          works, hence requiring a Hudson build before committing.

          So perhaps this is not super critical, but at the same time I think the workflow
          I followed is not overly weird.

          mcrooney added a comment - It is true that it only occurs when changing a configuration, but it has led to data loss a number of times for us as it wipes out the old checkout where I had been doing some uncommitted work on files related to Hudson. When initially setting up a project, I end up changing the configuration a couple times, which is also the time when I'd be experimenting with local changes to build files and such, as I don't want to commit until I know it works, hence requiring a Hudson build before committing. So perhaps this is not super critical, but at the same time I think the workflow I followed is not overly weird.

          mcrooney added a comment -

          Agh, this really kills my iteration speed on setting up and configuring new
          projects in Hudson. It isn't uncommon to add a second repository and I have to
          wait 10 minutes for the first repository to check it again (it's large) just to
          test using something from that new second repository.

          Also it just caused data loss again, the local changes I had in the original
          working checkout got stomped over :'[ I don't really find this to be a minor issue.

          mcrooney added a comment - Agh, this really kills my iteration speed on setting up and configuring new projects in Hudson. It isn't uncommon to add a second repository and I have to wait 10 minutes for the first repository to check it again (it's large) just to test using something from that new second repository. Also it just caused data loss again, the local changes I had in the original working checkout got stomped over :'[ I don't really find this to be a minor issue.

            Unassigned Unassigned
            mcrooney mcrooney
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: