You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2005/01/05 16:22:05 UTC
RE: commiter help needed with site update
I have updated /www/james.apache.org to reflect to the change from CVS to
SVN, and updated the site.
The new local command is `svn up`.
When we move the site from server/trunk to site/, I'll update the checkout
again.
--- Noel
Re: commiter help needed with site update
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I also wondered about using xdoclet to make nice mailet & matcher docs
> from javadocs, or of using a templated format. I don't think its an
> issue yet, but it may be if we follow the obvious path of moving
> "provided" M&M's out of James and let them exhibit their own
> lifecycles. At which point we'll need to version and aggregate their
> documentation too.
That would be nice, though even just simple things like including @since
and what parameters a mailet and matcher takes would be nice. Yes
ideally we could extract that to xdocs, but gathering that info would be
a first step IMO. Maybe defining a structure helps us get in the habbit
of that.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Re: commiter help needed with site update
Posted by Danny Angus <da...@gmail.com>.
> Cool. And we should look at pulling in content for jSieve, too. What is
> your plan?
Its weak at the moment but I've just pulled together a solution to a
similar problem internally at work, how to get multiple different
product version document sets and a largely independant set of general
docs integrated into a simple process.
Work's solution uses Maven, I'm trying to figure out how I can
translate this to an ant build.
What we do as part of the release process is simply to generate the
product documentation and publish it into a directory named with the
version label, the "site" is also xdocs and exists as another project
with mainly just the "general" xdocs in it, therefore you can edit and
version the site content without troubling the product docs, and
publish product docs during releases without having to become
concerned with the main site.
We'll need to think about how we deal with multiple doc sets in terms
of profligate use of disk space, perhaps we limit ourselves to
publishing "stable". But by separating docs from src and bin downloads
we make every older version's docs available as a straightforward
download->unzip
Not sure exactly where this'll end up yet, but thats my current
thinking on process.
I also wondered about using xdoclet to make nice mailet & matcher docs
from javadocs, or of using a templated format. I don't think its an
issue yet, but it may be if we follow the obvious path of moving
"provided" M&M's out of James and let them exhibit their own
lifecycles. At which point we'll need to version and aggregate their
documentation too.
d.
Re: commiter help needed with site update
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>>>Do I just check in files to the new location and "delete" using svn?
>>>
>>>No! Please. :-)
>>
>>So CVS(remove) != SVN(delete)?
>
>
> Why delete something when you want to move it? Delete it only if you want
> it to go away entirely (except for people using -r to access old material).
You went into this rant about preserving history, so I thought perhaps
we were talking more about than just moving something or that
SVN(delete) removed history. I understand if you want to move
something, you would use SVN(move) or CVSNT(move), while with CVS you
have to CVS(add)/CVS(delete).
I probably was just lacking context, so don't worry it...
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
RE: commiter help needed with site update
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas wrote:
>>>Do I just check in files to the new location and "delete" using svn?
>> No! Please. :-)
> So CVS(remove) != SVN(delete)?
Why delete something when you want to move it? Delete it only if you want
it to go away entirely (except for people using -r to access old material).
--- Noel
Re: commiter help needed with site update
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>Do I just check in files to the new location and "delete" using svn?
>
> No! Please. :-)
So CVS(remove) != SVN(delete)?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
RE: commiter help needed with site update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Do I just check in files to the new location and "delete" using svn?
No! Please. :-)
> Or should we be thinking about moving history too?
Saving history is one of my pet peeves. Thou Shalt Preserve History. :-)
You can just do `svn move <src> <dest>`, at which time we'll need to change
the build process.
> I have a plan for Java docs etc so don't worry about that
Cool. And we should look at pulling in content for jSieve, too. What is
your plan?
--- Noel
Re: commiter help needed with site update
Posted by Danny Angus <da...@gmail.com>.
Thanks Noel.
I'll start on that next.
Do I just check in files to the new location and "delete" using svn?
Or should we be thinking about moving history too?
(I have a plan for Java docs etc so don't worry about that)
d.
/On Wed, 5 Jan 2005 10:22:05 -0500, Noel J. Bergman <no...@devtech.com> wrote:
> I have updated /www/james.apache.org to reflect to the change from CVS to
> SVN, and updated the site.
>
> The new local command is `svn up`.
>
> When we move the site from server/trunk to site/, I'll update the checkout
> again.
>
> --- Noel
>
>