Checking in our site

[Matthieu Riou <ma...@gmail.com>]

Hi guys,

It's a good idea to check our full website for 1.0 in, so it can be
retrieved in case of needs and also published at some different location
later on when we'll be updating everything for the next release. So we can
either:

1. Check it in the release branches -> looong checkout
2. Create a new site directory beside trunk, tags and branches to hold the
different site versions (like site/1.0).

I'd personally go for #2, any strong opposing opinion? Bike shed bait.

Matthieu

Re: Checking in our site

[Matthieu Riou <ma...@gmail.com>]

Btw forgot to mention, the issue is also site backup, in case the whole
world goes down. AFAIK confluence sites aren't backed up.

On 5/29/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Are you suggesting saving the HTML files or the Confluence markup? All
> those pages include a lot of other smaller pages, backing them up could take
> a little while. I guess we could come up with some little smart spider
> script for Confluence though.
>
> Matthieu
>
> On 5/29/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > How about versioning only the documentation (user guide, programmer's
> > guide, BPEL compliance, javadoc) instead of the whole site?   That way, we
> > could have a documentation index that would include all versions of the
> > documentation.   We could do this by copying only the relevant documentation
> > pages in the same space.  The other pages are 'live' documents and I would
> > rather have people always access the latest version from the website (
> > e.g. homepage, roadmap, ...).
> >
> > This option, like option 2 below, offers the advantage that we can go
> > and patch/augment the documentation for past versions if need be.  This is
> > useful to document known bugs, limitations, etc.
> >
> > alex
> >
> >
> > On 5/29/07, Matthieu Riou < matthieu.riou@gmail.com> wrote:
> > >
> > > Hi guys,
> > >
> > > It's a good idea to check our full website for 1.0 in, so it can be
> > > retrieved in case of needs and also published at some different
> > > location
> > > later on when we'll be updating everything for the next release. So we
> > > can
> > > either:
> > >
> > > 1. Check it in the release branches -> looong checkout
> > > 2. Create a new site directory beside trunk, tags and branches to hold
> > > the
> > > different site versions (like site/1.0).
> > >
> > > I'd personally go for #2, any strong opposing opinion? Bike shed bait.
> > >
> > >
> > > Matthieu
> > >
> >
> >
>

Re: Checking in our site

[Assaf Arkin <ar...@intalio.com>]

On 5/29/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> I was thinking copying the pages in Confluence itself (so the Confluence
> markup, not the HTML).
>
> If that's not easily possible, then I think we should migrate the
> documentation outside of Confluence to a system that scales better, both
> in
> terms of versioning and editing/aggregation.   I'm thinking something like
> Textile/Markdown wrapped with Haml+Sass and everything sitting in a
> separate
> section of our SVN.


Markdown is slightly easier for authoring, it reads more like text you'd
want to read (when not formatted as HTML), but you sometimes bump into
can't-quite-do cases. Textile deals with those better, at the expense of
something that looks a little more like a markup language.

I personally prefer Textile if the expected output is HTML.

Of course, the state of the art is editing either one using a text editor,
and SVN managing the versioning yourself.

Assaf

And we need to start exporting the Confluence site as backup!
>
> alex
>
>
>
> On 5/29/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > Are you suggesting saving the HTML files or the Confluence markup? All
> > those pages include a lot of other smaller pages, backing them up could
> take
> > a little while. I guess we could come up with some little smart spider
> > script for Confluence though.
> >
> > Matthieu
> >
> > On 5/29/07, Alex Boisvert <bo...@intalio.com> wrote:
> > >
> > > How about versioning only the documentation (user guide, programmer's
> > > guide, BPEL compliance, javadoc) instead of the whole site?   That
> way, we
> > > could have a documentation index that would include all versions of
> the
> > > documentation.   We could do this by copying only the relevant
> documentation
> > > pages in the same space.  The other pages are 'live' documents and I
> would
> > > rather have people always access the latest version from the website (
> > > e.g. homepage, roadmap, ...).
> > >
> > > This option, like option 2 below, offers the advantage that we can go
> > > and patch/augment the documentation for past versions if need
> be.  This is
> > > useful to document known bugs, limitations, etc.
> > >
> > > alex
> > >
> > >
> > > On 5/29/07, Matthieu Riou < matthieu.riou@gmail.com> wrote:
> > > >
> > > > Hi guys,
> > > >
> > > > It's a good idea to check our full website for 1.0 in, so it can be
> > > > retrieved in case of needs and also published at some different
> > > > location
> > > > later on when we'll be updating everything for the next release. So
> we
> > > > can
> > > > either:
> > > >
> > > > 1. Check it in the release branches -> looong checkout
> > > > 2. Create a new site directory beside trunk, tags and branches to
> hold
> > > > the
> > > > different site versions (like site/1.0).
> > > >
> > > > I'd personally go for #2, any strong opposing opinion? Bike shed
> bait.
> > > >
> > > >
> > > > Matthieu
> > > >
> > >
> > >
> >
>

Re: Checking in our site

[Alex Boisvert <bo...@intalio.com>]

I was thinking copying the pages in Confluence itself (so the Confluence
markup, not the HTML).

If that's not easily possible, then I think we should migrate the
documentation outside of Confluence to a system that scales better, both in
terms of versioning and editing/aggregation.   I'm thinking something like
Textile/Markdown wrapped with Haml+Sass and everything sitting in a separate
section of our SVN.

And we need to start exporting the Confluence site as backup!

alex



On 5/29/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Are you suggesting saving the HTML files or the Confluence markup? All
> those pages include a lot of other smaller pages, backing them up could take
> a little while. I guess we could come up with some little smart spider
> script for Confluence though.
>
> Matthieu
>
> On 5/29/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > How about versioning only the documentation (user guide, programmer's
> > guide, BPEL compliance, javadoc) instead of the whole site?   That way, we
> > could have a documentation index that would include all versions of the
> > documentation.   We could do this by copying only the relevant documentation
> > pages in the same space.  The other pages are 'live' documents and I would
> > rather have people always access the latest version from the website (
> > e.g. homepage, roadmap, ...).
> >
> > This option, like option 2 below, offers the advantage that we can go
> > and patch/augment the documentation for past versions if need be.  This is
> > useful to document known bugs, limitations, etc.
> >
> > alex
> >
> >
> > On 5/29/07, Matthieu Riou < matthieu.riou@gmail.com> wrote:
> > >
> > > Hi guys,
> > >
> > > It's a good idea to check our full website for 1.0 in, so it can be
> > > retrieved in case of needs and also published at some different
> > > location
> > > later on when we'll be updating everything for the next release. So we
> > > can
> > > either:
> > >
> > > 1. Check it in the release branches -> looong checkout
> > > 2. Create a new site directory beside trunk, tags and branches to hold
> > > the
> > > different site versions (like site/1.0).
> > >
> > > I'd personally go for #2, any strong opposing opinion? Bike shed bait.
> > >
> > >
> > > Matthieu
> > >
> >
> >
>

Re: Checking in our site

[Matthieu Riou <ma...@gmail.com>]

Are you suggesting saving the HTML files or the Confluence markup? All those
pages include a lot of other smaller pages, backing them up could take a
little while. I guess we could come up with some little smart spider script
for Confluence though.

Matthieu

On 5/29/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> How about versioning only the documentation (user guide, programmer's
> guide, BPEL compliance, javadoc) instead of the whole site?   That way, we
> could have a documentation index that would include all versions of the
> documentation.   We could do this by copying only the relevant documentation
> pages in the same space.  The other pages are 'live' documents and I would
> rather have people always access the latest version from the website ( e.g.
> homepage, roadmap, ...).
>
> This option, like option 2 below, offers the advantage that we can go and
> patch/augment the documentation for past versions if need be.  This is
> useful to document known bugs, limitations, etc.
>
> alex
>
>
> On 5/29/07, Matthieu Riou <ma...@gmail.com> wrote:
> >
> > Hi guys,
> >
> > It's a good idea to check our full website for 1.0 in, so it can be
> > retrieved in case of needs and also published at some different location
> > later on when we'll be updating everything for the next release. So we
> > can
> > either:
> >
> > 1. Check it in the release branches -> looong checkout
> > 2. Create a new site directory beside trunk, tags and branches to hold
> > the
> > different site versions (like site/1.0).
> >
> > I'd personally go for #2, any strong opposing opinion? Bike shed bait.
> >
> > Matthieu
> >
>
>

Re: Checking in our site

[Alex Boisvert <bo...@intalio.com>]

How about versioning only the documentation (user guide, programmer's guide,
BPEL compliance, javadoc) instead of the whole site?   That way, we could
have a documentation index that would include all versions of the
documentation.   We could do this by copying only the relevant documentation
pages in the same space.  The other pages are 'live' documents and I would
rather have people always access the latest version from the website (e.g.
homepage, roadmap, ...).

This option, like option 2 below, offers the advantage that we can go and
patch/augment the documentation for past versions if need be.  This is
useful to document known bugs, limitations, etc.

alex


On 5/29/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Hi guys,
>
> It's a good idea to check our full website for 1.0 in, so it can be
> retrieved in case of needs and also published at some different location
> later on when we'll be updating everything for the next release. So we can
> either:
>
> 1. Check it in the release branches -> looong checkout
> 2. Create a new site directory beside trunk, tags and branches to hold the
> different site versions (like site/1.0).
>
> I'd personally go for #2, any strong opposing opinion? Bike shed bait.
>
> Matthieu
>