[ 
https://issues.jenkins-ci.org/browse/JENKINS-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159117#comment-159117
 ] 

Chris Huseman commented on JENKINS-11028:
-----------------------------------------

It looks like this is an issue in SVNKit/svn libraries.

It fails on a case-insensitive file system when the path to the working copy 
directory is different on disk than in the external.

So, for example:

Assume there is a src/Web/scripts folder that is tracked in the svn repository.
Assume there is an external defined as: https://svn.foo.com/web/scripts/baz 
src/web/scripts/baz

Using the SVN command-line client or SVNKit, the status of src/Web/scripts/baz 
in the working copy is unknown.

The fix is to match the case of the external path: 
https://svn.foo.com/web/scripts/baz src/Web/scripts/baz

The status is then properly identified as an external and not deleted by 
hudson.scm.subversion.UpdateWithCleanUpdater.

                
> Emulate clean checkout deletes svn:externals folders if the relative local 
> subdirectory is several levels deep
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JENKINS-11028
>                 URL: https://issues.jenkins-ci.org/browse/JENKINS-11028
>             Project: Jenkins
>          Issue Type: Bug
>          Components: subversion
>    Affects Versions: current
>            Reporter: schallm
>
> We set all externals at the root level (trunk) of our svn tree.  This is so 
> all externals are easily found both manually and programmatically without 
> recursion of all folders.  On our trunk folder we have the svn:external set 
> similar to the following:
> https://svn.foo.com/bar/bin lib/bar
> https://svn.foo.com/web/scripts/baz src/web/scripts/baz
> When Jenkin's svn module does a build with the "Emulate clean ..." option 
> set, the lib/bar folder is not removed, however the src/web/scripts/baz 
> folder is.  When the svn update is called, the folder is brought back down.  
> We have several large externals that are having this problem causing our 
> builds to take a long time due to the unnecessary removal and re-download of 
> the external files.
> It would be great if all external folders were left alone.
> Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to