[
https://issues.apache.org/jira/browse/DERBY-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536348#comment-13536348
]
Rick Hillegas commented on DERBY-6007:
--------------------------------------
Here is what I did to implement the plan described in the previous comment:
(1)
In my website client I saved the generated content in a tarball. In retrospect,
I should have used "svn export" to do this; that would have removed the version
control information in the copy (see below).
cd .../build/site
tar cf ../../../site.tar .
(2)
In my website client:
cd .../build
svn delete site
Committed at subversion revision 1423860.
(3)
In another window and subtree, I checked out all of the content at
https://svn.apache.org/repos/infra/websites/production/db/content, added a
derby subdirectory, and committed this subdirectory at subversion revision
843107.
Then in my website client, I did the following:
cd .../build
svn propset svn:externals
"https://svn.apache.org/repos/infra/websites/production/db/content/derby/ site"
.
svn update
Then I committed the propset in the build directory at subversion revision
1423984.
(4)
In my website client:
cd .../build/site
tar xf ../../../site.tar
Then I used the svn export command to remove the version control information
which had been tar'd up along with the directory tree. There were a number of
steps here and I made some mistakes along the way. But I think I ended up with
a correctly shaped directory of files not under version control.
I moved the contents of the doc directory to the side because I remembered from
last week that adding all of the published docs for all of the previous
releases of derby took a long time and failed at the end. I decided to checkin
everything except the docs and then check them in one release at a time.
mkdir ../z
mv docs/* ../z/
svn add *
I committed this work at subversion revision 843115.
cd docs
Then I committed the published docs, one release at a time like this:
mv ../../z/10.0 ./
svn add 10.0
svn commit ...
The published docs were committed at these revision stamps:
10.0: revision 843118
10.1: revision 843121
10.2: revision 843124
10.3: revision 843125
10.4: revision 843126
10.5: revision 843128
10.6: revision 843129
10.7: revision 843130
10.8: revision 843131
10.9: revision 843134
Then as a sanity-check, I built the Derby website in my client. A cursory
inspection of the results looked good to me. However, I noticed that the build
ended up creating a file which was no longer under subversion control:
? build/site/broken-links.xml
I think that the "svn propset" command clobbered the hidden status of this
file. I decided to add this vacuous file to the repository and I committed that
change at subversion revision 843145. Along the way I discovered the following
fun fact: The re-directed generated content subtree is not affected by commits
to the larger website source tree in which it is embedded. I think this means
that when you change the website, you have to make 2 commits:
i) You have to commit the website source.
ii) And you have to commit the generated content subtree independently.
Maybe someone understands how to make this work in a more coordinated fashion.
I also discovered that if you type "svn status" high up in the website source
tree, then you will see the redirected subtree marked with an X for "externals":
X build/site
I googled around about this and it may be that a later edition of subversion
does not show this status by default. You can suppress this status information
with the following switch:
svn status --ignore-externals -q
> Migrate Derby website to new Apache website publication machinery
> -----------------------------------------------------------------
>
> Key: DERBY-6007
> URL: https://issues.apache.org/jira/browse/DERBY-6007
> Project: Derby
> Issue Type: Improvement
> Components: Web Site
> Reporter: Rick Hillegas
> Attachments: derby-6007-01-aa-prepForDocsCheckin.diff
>
>
> As of January 2013, the Apache website will no longer be refreshed from the
> /www/db.apache.org/derby directory tree on minotaur. Instead, projects will
> need to put their website content under subversion control and tell the
> Infrastructure team where that subversion repository is. Most of Derby's
> website is subversion controlled. However, the docs and alpha javadoc
> directories are not. We will need to put docs and alpha javadoc under
> subversion control along with the rest of the Derby website. Then we will
> need to file an issue, telling the Infrastructure team where our content
> lives. For an example of such an issue, see
> https://issues.apache.org/jira/browse/INFRA-5215
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
