[JENKINS-3083] Better support for multiple SVN roots

We are able to define, checkout and use multiple SVN roots with Hudson. So far,

so nice. But two of the most important actions on the SVN do not reflect this

feature.

1. I should be able to define the update/checkout strategy on each root

separately. The kind of sources in the different roots may be entirely different

requiring a different strategy for the root. As well, the update should be done

for each root separately, if it fails, only a fresh checkout of the failed root

should be performed. A sidemark, a no-update or only-manual-update-clause would

be very sexy too for repositories changing very rarely (e.g. we store the JDK we

use for compilation during the build as well in the repository, this changes

only once in two years)

2. The triggers on the SCM (polling) should be aware of the different roots.

event better would be if one could define polling triggers on sub-parts of one root.

---
Originally reported by mdaenzer, imported from: Better support for multiple SVN roots

• status: Open
  
• priority: Major
  
• component(s): subversion-plugin
  
• resolution: Unresolved
  
• votes: 2
  
• watchers: 1
  
• imported: 20251212-090250
  

Raw content of original issue

We are able to define, checkout and use multiple SVN roots with Hudson. So far,

so nice. But two of the most important actions on the SVN do not reflect this

feature.


1. I should be able to define the update/checkout strategy on each root

separately. The kind of sources in the different roots may be entirely different

requiring a different strategy for the root. As well, the update should be done

for each root separately, if it fails, only a fresh checkout of the failed root

should be performed. A sidemark, a no-update or only-manual-update-clause would

be very sexy too for repositories changing very rarely (e.g. we store the JDK we

use for compilation during the build as well in the repository, this changes

only once in two years)


2. The triggers on the SCM (polling) should be aware of the different roots.

event better would be if one could define polling triggers on sub-parts of one root.

• environment: Platform: All, OS: All