lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation
Date Tue, 08 Nov 2011 18:55:24 GMT
I noticed that we have a bit of documentation in the 'site' directory of
the, and the trunk directory.  Which one are we using to link to the
website, the one in trunk or the site folder?  I feel that maybe we could
still keep the docs in trunk zipped for each release and tag, then extract
that to the site directory when we want to release documentation.  At least
then it would keep our SVN uncluttered.  To be honest, though, I don't
really know how documentation is stored in other projects, so I'll admit
I'm not even 100% sure if that's a plausible solution.


On Mon, Nov 7, 2011 at 11:55 PM, Prescott Nasser <geobmx540@hotmail.com>wrote:

>
> My intention is to link it to the website, so we have browsable
> documentation
>
>
>
>
>
> ----------------------------------------
> > Date: Mon, 7 Nov 2011 19:26:23 -0800
> > From: currens.chris@gmail.com
> > To: lucene-net-dev@lucene.apache.org
> > Subject: Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation
> >
> > I don't understand why we have the rendered html in the docs. I don't
> mind
> > having the .chm rendered and put in the repo, but the entire HTML
> > documentation spans 8,000 files and over 100mb. The CHM comes in at
> around
> > 15mb.
> >
> > I don't think it's necessary to have both in the repo, but if the
> consensus
> > is to keep them both, I think we should bundle the HTML docs in a zip,
> > instead of being added as loose files, at least in trunk. I think it's
> > kinda silly the way it is now, and SVN does better at handling 1 large
> file
> > versus 8,000 smaller ones.
> >
> > On Mon, Nov 7, 2011 at 6:53 AM, Michael Herndon <
> mherndon@wickedsoftware.net
> > > wrote:
> >
> > > @Stefan.
> > >
> > > I wouldn't worry about the taking the blame, you've done plenty to
> help out
> > > and there is no way to catch everything. We'll learn as we go.
> > >
> > > As svnpub is the only option and since we can't run the binary version
> that
> > > uses ASP.NET, we'll need to probably take your suggestion commit the
> > > smaller chunks of html then.
> > >
> > > I'll do it manually this time and see if I can't write a script that
> > > automates it in the future.
> > >
> > > @Chris, thanks for the fixes to the build scripts this weekend.
> > >
> > > - Michael
> > >
> > >
> > > On Mon, Nov 7, 2011 at 9:20 AM, Stefan Bodewig <bodewig@apache.org>
> wrote:
> > >
> > > > On 2011-11-07, Michael Herndon wrote:
> > > >
> > > > > I can rebuild it, but the trick is replacing the version of it in
> svn
> > > so
> > > > > that it does not cause svnsync and cms to choke. Last time I just
> > > pushed
> > > > it
> > > > > into branch/site/docs. However, that is not publicly visible for
> the
> > > > > incubation website, so Prescott had to do an svn move.
> > > >
> > > > When I recommended to do the svn move I didn't realize we were
> talking
> > > > about that many files. I simply didn't check, sorry.
> > > >
> > > > > I'm not quite sure how to go about it this time around. I would
> push it
> > > > to
> > > > > jira, but it caps uploads at 10 mb.
> > > >
> > > > Then it still had to go to svn in some way.
> > > >
> > > > Personally I'm not a friend of generated documents in svn but I'm in
> a
> > > > minority here.
> > > >
> > > > With svnpubsub being your only option I think the only thing you can
> do
> > > > is split the commit into smaller chunks, committing 100 or 200 files
> at
> > > > a time. Maybe infra has better ideas than that, I don't.
> > > >
> > > > Stefan
> > > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message