On 12/31/13, 10:43 AM, Oliver Heger wrote: > 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.
|Thanks, that seems to have fixed it. I guess somehow my local build must have generated files with inconsistent line endings. Phil ||||| > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
