accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1490088 - in /accumulo/site/branches: ./ git/ git/content/git.mdtext git/templates/sidenav.mdtext git/templates/skeleton.html
Date Wed, 05 Jun 2013 23:58:29 GMT
Author: elserj
Date: Wed Jun  5 23:58:28 2013
New Revision: 1490088

ACCUMULO-1498 Copy of the site's trunk with a start to the Git WIP document

      - copied from r1490085, accumulo/site/trunk/
    accumulo/site/branches/git/content/git.mdtext   (with props)

Added: accumulo/site/branches/git/content/git.mdtext
--- accumulo/site/branches/git/content/git.mdtext (added)
+++ accumulo/site/branches/git/content/git.mdtext Wed Jun  5 23:58:28 2013
@@ -0,0 +1,108 @@
+Title: Apache Accumulo Git WIP
+Notice:    Licensed to the Apache Software Foundation (ASF) under one
+           or more contributor license agreements.  See the NOTICE file
+           distributed with this work for additional information
+           regarding copyright ownership.  The ASF licenses this file
+           to you under the Apache License, Version 2.0 (the
+           "License"); you may not use this file except in compliance
+           with the License.  You may obtain a copy of the License at
+           .
+           .
+           Unless required by applicable law or agreed to in writing,
+           software distributed under the License is distributed on an
+           KIND, either express or implied.  See the License for the
+           specific language governing permissions and limitations
+           under the License.
+## Git
+[Git]( is an open source, distributed version control system
+which has become very popular in large, complicated software projects due to its
+efficient handling of multiple, simultaneously and independently developed brances
+of source code.
+## The plan
+There are multiple steps that are required of us to fully transition from active
+development against Subversion to Git. Each of these requires consensus (lazy or
+not) from the team along with documentation that developers, both existing and
+current, can reference to understand how and what to do.
+### Workflow Background
+Likely the most contested subject matter regarding switching an active team from
+one SCM tool to another is a shift in the development paradigm.
+Some background, the common case, as is present with this team, is that
+developers coming from a Subversion history are very light on merging being a
+critical consideration on how to perform development. Because mering in
+Subversion is typically of no consequence to the complete view of history, not
+to mention that Subversion allows "merging" of specific revisions instead of
+sub-trees. As such, a transition to Git typically requires a shift in mindset in
+which a fix is not arbitrarily applied to trunk (whatever the main development
+is called), but the fix should be applied to the earliest, non end-of-life
+(EOL) version of the application.
+For example, say there is a hypothetical application which has just released
+version-3 of their software and have shifted their development to a version-4
+WIP. Version-2 is still supported, while version-1 was just EOL'ed. Each version
+still has a branch. A bug was just found which affects all released versions of
+this application. In Subversion, considering the history in the repository, it
+is of no consequence where the change is initially applied, because a Subversion
+merge is capable of merging it to any other version. History does not suffer
+because Subversion doesn't have the capacities to accurately track the change
+across multiple branches. In Git, to maintain a non-duplicative history, it is
+imperative that the developer choose the correct branch to fix the bug in. In
+this case, since version-1 is EOL'ed, version-2, version-3 and the WIP 
+version-4 are candidates. The earliest version is obviously version-2; so, the
+change should be applied in version-2, merged to version-3 and then the
+version-4 WIP.
+The importance of this example is making a best-attempt to preserve history when
+using Git. While Git does have commands like cherry-pick which allow the
+contents of a commit to be applied from one branch to another which are not
+candidates to merge without conflict (which is typically the case when merging 
+a higher version into a lower version), this results in a duplication of that
+commit in history when the two trees are eventually merged together. While Git
+is smart enough to not attempt to re-apply the changes, history still contains
+the blemish.
+The purpose of this extravagant example is to outline, in the trivial case, how
+the workflow decided upon for development is very important and has direct
+impact on the efficacy of the advanced commands bundled with Git.
+### Proposed Workflow
+I'll try to summarize what has thus far been agreed upon by vocal
+committers/PMC members on I will attempt to refer to
+concepts in a abstract sense. Concrete example will be later created.
+1. Active development is performed concurrently over no less than two version of
+Apache Accumulo at any one point in time. As such, the workflow must provide
+guidance on how and where changes should be made which apply to multiple
+versions and how to ensure that such changes are contained in all applicable
+2. Releases are considered extremely onerous and time-consuming
+so no emphasis is placed on rapid iterations or development-cycles.
+3. New features typically have lengthy development cycles in which more than one
+developer contributes to the creation of the new feature from planning, to
+implementation, to scale testing. Mechanisms/guidance should be provided for
+multiple developers to teach contribute to a remote-shared resource.
+4. The repository should be the irrefutable, sole source of information
+regarding the development of Apache Accumulo, and, as such, should have
+best-efforts given in creating a clean, readable history without any single
+entity having write access and all changes flowing through he/she. In other
+words, the developers are the ones responsible for ensuring that previous
+releases are preserved to meet ASF policy, for not rewriting any public history
+of code not yet officially released (also ASF policy relevant) and for a
+best-effort to be given to avoid duplicative commits appearing in history
+created by the application of multiple revisions which have different
+identifying attributes but the same contents (git-rebase and git-cherry-pick).
+## The implementation 

Propchange: accumulo/site/branches/git/content/git.mdtext
    svn:eol-style = native

Modified: accumulo/site/branches/git/templates/sidenav.mdtext
--- accumulo/site/branches/git/templates/sidenav.mdtext (original)
+++ accumulo/site/branches/git/templates/sidenav.mdtext Wed Jun  5 23:58:28 2013
@@ -1,28 +1,29 @@
 # Project
  - [Home](/)
- - [Downloads](/downloads)
- - [Features](/notable_features.html)
+ - [Downloads](downloads)
+ - [Features](notable_features.html)
  - [License](
 # Community
- - [Get Involved](/get_involved.html)
- - [Mailing Lists](/mailing_list.html)
- - [People](/people.html)
+ - [Get Involved](get_involved.html)
+ - [Mailing Lists](mailing_list.html)
+ - [People](people.html)
 # Development
- - [Source & Guide](/source.html)
+ - [Source & Guide](source.html)
+ - [Git WIP](git.html)
  - [Issues](
  - [Builds](
 # Documentation
- - Manual [1.4](/1.4/user_manual) / [1.5](/1.5/accumulo_user_manual.html)
- - Javadoc [1.4](/1.4/apidocs) / [1.5](/1.5/apidocs)
- - Examples [1.4](/1.4/examples) / [1.5](/1.5/examples)
- - [Screenshots](/screenshots.html)
- - [Papers & Other Links](/papers.html)
- - [Glossary](/glossary.html)
+ - Manual [1.4](/1.4/user_manual) / [1.5](1.5/accumulo_user_manual.html)
+ - Javadoc [1.4](/1.4/apidocs) / [1.5](1.5/apidocs)
+ - Examples [1.4](/1.4/examples) / [1.5](1.5/examples)
+ - [Screenshots](screenshots.html)
+ - [Papers & Other Links](papers.html)
+ - [Glossary](glossary.html)
 # ASF links
   - [Apache Software Foundation](
   - [Sponsorship](
   - [Security](
-  - [Thanks](
\ No newline at end of file
+  - [Thanks](

Modified: accumulo/site/branches/git/templates/skeleton.html
--- accumulo/site/branches/git/templates/skeleton.html (original)
+++ accumulo/site/branches/git/templates/skeleton.html Wed Jun  5 23:58:28 2013
@@ -17,7 +17,7 @@
     See the License for the specific language governing permissions and
     limitations under the License.
-  <link href="/css/accumulo.css" rel="stylesheet" type="text/css">
+  <link href="css/accumulo.css" rel="stylesheet" type="text/css">
   <title>{% block title %}{{ headers.title }}{% endblock %}</title>
   <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -49,7 +49,7 @@
   <div id="bannertext">
-    <img id="logo" alt="Apache Accumulo" src="/images/accumulo-logo.png"/>&trade;
+    <img id="logo" alt="Apache Accumulo" src="images/accumulo-logo.png"/>&trade;
   <div id="content">
@@ -59,7 +59,7 @@
   <div id="footer">
     <a alt="Apache Software Foundation" href="">
-      <img id="asf-logo" alt="Apache Software Foundation" src="/images/feather-small.gif"/
+      <img id="asf-logo" alt="Apache Software Foundation" src="images/feather-small.gif"/
     <div class="copyright">

View raw message