Am 31.12.2013 19:09, schrieb Phil Steitz: > On 12/31/13, 7:34 AM, sebb wrote: >> On 31 December 2013 04:54, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 12/30/13, 4:04 PM, Phil Steitz wrote: >>>> I ran with scissors and tried mvn site-deploy and it seems to have >>>> (sic) *deleted* the previous javadoc versions from the site svn. >>>> How can I get these back? How can I avoid this trauma each time I >>>> try to publish the site? I guess I can just cp the local mvn site >>>> gen to a direct checkout the svn pub-sub. Is that what others do? >>>> Sorry I probably missed good instructions on this somewhere. >>>> >>>> Phil >>> Finally got this fixed (mostly). I was able to get all but 1.6 >>> apidocs from previous revisions. When I tried to svn add the 1.6 >>> apidocs (grabbed from an earlier rev checkout) I got this >>> >>> svn: E200009: File '/Users/psteitz/pool-site/api-1.6/index-all.html' >>> has inconsistent newlines >>> svn: E135000: Inconsistent line ending style >>> >>> I got the same result when I >>> 0) extracted the apidocs from the binary release >>> 1) rebuilt the apidocs from the source release >>> I finally succeeded when I rebuilt the apidocs from a fresh checkout >>> of the 1.6 tag. I thought our tools were supposed to handle this >>> stuff $#%#$^! >>> >>> I also had to svn revert the JIRA and Clirr report html files >>> because I got the same error when I tried to commit the full set of >>> changes with these included. When viewing these reports, the >>> javadoc menus are borked. Anyone better capable of wrestling with >>> this is welcome to try to fix it. The files in pool trunk generate >>> a good site. I am pretty sure my local svn props are set correctly. >>> >>> Moral of the story: don't mess with mvn site-deploy unless you have >>> "nothing to lose" in the filesystem. Also, there must be something >>> screwed up in line-ending handling in svn pub-sub or the way our >>> tooling is handling it (or some local config I am missing?). At >>> this point, I am inclined to nuke the current repo and rebuild from >>> a clean copy of a locally generated site. Any better ideas? >> I thought it was possible to tell Maven publish not to delete certain >> directories when it updated the site. >> These exclusions need to be added to the POM, and then managed manually. > > Thanks, Sebb. At this point, I would be happy just to be able to > commit manually. I still have two files that I can't commit - the > jira and clirr reports in the top-level directory. Interestingly, > these are the *only* two files that have svn:eol set (correctly to > native). *None* of the rest of the files have *any* properties > set. I did a little comparative shopping and saw that the [lang] > and [dbcp] sites also have no properties defined on any of the > files. I guess the maven auto-stomp thing does not set properties > or use the local svn settings? Would appreciate any svn wizardry > advice to work around this problem.
>From my experience, this svn error message can be fixed by ensuring that the affected files have consistent line endings - either windows or unix style. I would recommend running tools like dos2unix over them. HTH Oliver > > Phil >>> Phil >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
