We're seeing random deletions of our workspace even without any interaction with SVN. We have a few jobs where we turned off SCM polling and we've seen the workspace mysteriously go bye-bye for those.

Can anyone explain what might be the cause?

I'm constantly snapping our build machine because of this problem. Since the project we are working on has multiple versions, it is more convenient to keep them in a single, custom workspace dir. If for some reason SVN locks one of the project dirs, the next time it updates the entire workspace is rm -rf'ed

Is there a plugin or a way to sidestep this issue until it is resolved?

Still there with subversion-plugin 2.5, our configuration is pulling many folders under one directory (as it would resemble when the library is built) and it should look like this (assuming we're in $WORKSPACE of the job):

.
├── COPYING
├── COPYING.LESSER
├── coverage.xml
├── src
│   ├── commands
│   ├── core
│   ├── __init__.py
│   ├── ...
│   └── webshell
├── core_tests
│   ├── ...
│   ├── __init__.py
│   └── test_version.py
│
├──flake8.log
└── ...

We fetch different folders and put them all in src/ which then we export to PYTHONPATH when we run the unittests from core_tests (with nosetests).

The problem is that at each fetch from SVN even if we don't want and we specify this to SVN to only update we get the workspace src/ folder erased!

Is it possible to avoid this? A snippet of the fetch:

Switching to https://.../core at revision '2015-03-06T12:05:11.289 +0100'
D         __init__.py
A         tests
...

now comes the next checkout

Switching to https://.../lib at revision '2015-03-06T12:05:11.289 +0100'
D         core
D         data
D         datatypes
A         commands

as you can see the "D" will erase previous fetches afterwards adding the new ones. Is this the intended behavior?

Later addition: after a few more builds it seems it "fixes by itself" and concludes the build successful without any importation failures of any libraries (caused by the then deleted folders), not sure how correct this is how and needs an analysis from our part, but is this normal?

alghe:
In my experience the modules need to be ordered by increasing root folder depth, e.g. my first module checks out to `.`, and subsequent ones to `foo`, `bar`, etc. – maybe something similar helps in your situation.

Note that this issue is ancient and probably should not be revived. File new bugs, or (better if you're not sure it's a bug) ask the jenkinsci-users mailing list.

alghe: I agree with danielbeck, what you described does not seem to be related to the initial point of this issue. Also, I don't fully understand what behaviour you expected. Can you please provide a manual list of svn commands that produce your desired behaviour? Then we can analyze how it differs from what Jenkins does.

Beside alghe comment from 2015, can anyone please explain what is this issue about and why is it still opened? Does the initial problem still exist? I tried digging all the above history, but I fail to find a clear scenario description defining the problem.