You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@calcite.apache.org by jh...@apache.org on 2019/03/27 23:39:20 UTC

[calcite] branch site updated (2850379 -> f971492)

This is an automated email from the ASF dual-hosted git repository.

jhyde pushed a change to branch site
in repository https://gitbox.apache.org/repos/asf/calcite.git.


 discard 2850379  Update instructions for publishing site; we previously used subversion, now we use git
     new f971492  Update instructions for publishing site; we previously used subversion, now we use git

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (2850379)
            \
             N -- N -- N   refs/heads/site (f971492)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 site/README.md | 5 +++++
 1 file changed, 5 insertions(+)


[calcite] 01/01: Update instructions for publishing site; we previously used subversion, now we use git

Posted by jh...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

jhyde pushed a commit to branch site
in repository https://gitbox.apache.org/repos/asf/calcite.git

commit f971492a98cdd9ed6203f29c374fc1dc8b99483d
Author: Julian Hyde <jh...@apache.org>
AuthorDate: Wed Mar 27 16:31:46 2019 -0700

    Update instructions for publishing site; we previously used subversion, now we use git
---
 site/README.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/site/README.md b/site/README.md
index 831f220..7f8e2b1 100644
--- a/site/README.md
+++ b/site/README.md
@@ -31,7 +31,7 @@ You can build the site manually using your environment or use the docker compose
 Site generation currently works best with ruby-2.5.1.
 
 1. `cd site`
-2. `svn co https://svn.apache.org/repos/asf/calcite/site target`
+2. `git clone https://gitbox.apache.org/repos/asf/calcite-site.git target`
 3. `sudo apt-get install rubygems ruby2.5-dev zlib1g-dev` (linux)
    `Use RubyInstaller to install rubygems as recommended at https://www.ruby-lang.org/en/downloads/` (Windows)
 4. `sudo gem install bundler`
@@ -63,14 +63,17 @@ running from within the directory:
 2. Install [docker-compose](https://docs.docker.com/compose/install/)
 
 ### Build site
+
 1. `cd site`
 2. `docker-compose run build-site`
 
 ### Generate javadoc
+
 1. `cd site`
 2. `docker-compose run generate-javadoc`
 
 ### Running development mode locally
+
 You can preview your work while working on the site.
 
 1. `cd site`
@@ -88,12 +91,14 @@ As you make changes to the site, the site will automatically rebuild.
 4. `git reset origin/master --soft`
 
 If you have not regenerated the javadoc and they are missing, restore them:
+
 6. `git reset -- apidocs/`
 7. `git reset -- testapidocs/`
 8. `git checkout -- apidocs/`
 9. `git checkout -- testapidocs/`
 
 Restore the avatica site
+
 10. `git reset -- avatica/`
 11. `git checkout -- avatica/`
 
@@ -125,7 +130,7 @@ sync with "master". Immediately after a release, the release manager
 will publish the site, including all of the features that have just
 been released. When making an edit to the site, a Calcite committer
 must commit the change to the git "master" branch (as well as
-subversion, to publish the site, of course). If the edit is to appear
+git, to publish the site, of course). If the edit is to appear
 on the site immediately, the committer should then cherry-pick the
 change into the "site" branch.  If there have been no feature-related
 changes on the site since the release, then "site" should be a