hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "GitAndHadoop" by SteveLoughran
Date Wed, 23 Dec 2009 14:10:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "GitAndHadoop" page has been changed by SteveLoughran.
The comment on this change is: More on the process, some spelling corrections.
http://wiki.apache.org/hadoop/GitAndHadoop?action=diff&rev1=9&rev2=10

--------------------------------------------------

  
  You can create your own fork of the ASF project, put in branches and stuff as you desire.
GitHub prefer you to explicitly fork their copies of Hadoop.
  
-  1. Create a githib login at http://github.com/ ; Add your public SSH keys
+  1. Create a GitHub login at http://github.com/ ; Add your public SSH keys
-  1. Go to http://github.com/apache and search for the Hadoop and other apache projects you
want (avro is handy alongside the others)
+  1. Go to http://github.com/apache and search for the Hadoop and other Apache projects you
want (avro is handy alongside the others)
   1. For each project, fork. This gives you your own repository URL which you can then clone
locally with {{{git clone}}}
   1. For each patch, branch.
  
- At the time of writing (December 2009), github was updating its copy of the Apache repositories
every hour.
+ At the time of writing (December 2009), GitHub was updating its copy of the Apache repositories
every hour. As the Apache repositories were updating every 15 minutes, provided these frequencies
are retained, a GitHub-fork derived version will be at worst 1 hour and 15 minutes behind
the ASF's SVN repository. If you are actively developing on Hadoop, especially committing
code into the SVN repository, that is too long -work off the Apache repositories instead.
  
  == Building the source ==
  
@@ -91, +91 @@

  
  Each project comes with lots of tests; run {{{ant test}}} to run them. If you have made
changes to the build and tests fail, it may be that the tests never worked on your machine.
Build and test the unmodified source first. Then keep an eye on both the main source and any
branch you make. A good way to do this is to give a Continuous Integration server such as
Hudson this job: checking out, building and testing both branches.
  
+ Remember, the way Git works, your machine's own repository is something that other machines
can fetch from. So in theory, you could set up a Hudson server on another machine (or VM)
and have it pull and test against your local code. You will need to run it on a separate machine
to avoid your own builds and tests from interfering with the Hudson runs.
+ 
  == Branching ==
  
- Hadoop makes it easy to branch. The recommended process for working with apache projects
is: one branch per JIRA issue. That makes it easy to isolate development and track the development
of each change. It does mean if you have your own branch that you release, one that merges
in more than one issue, you have to invest some effort in merging everything in. Try not to
make changes in different branches that are hard to merge.
+ Git makes it easy to branch. The recommended process for working with Apache projects is:
one branch per JIRA issue. That makes it easy to isolate development and track the development
of each change. It does mean if you have your own branch that you release, one that merges
in more than one issue, you have to invest some effort in merging everything in. Try not to
make changes in different branches that are hard to merge, and learn your way round the git
rebase command to handle changes across branches.
  
  One thing you need to look out for is making sure that you are building the different Hadoop
projects together; that you have not published on one branch and built on another. This is
because both Ivy and Maven publish artifacts to shared repository cache directories.
  
@@ -116, +118 @@

  git branch
  }}}
  
- Remember, this branch is local to your machine. Nobody else can see it until you push up
your changes or generate a patch.
+ Remember, this branch is local to your machine. Nobody else can see it until you push up
your changes or generate a patch, or you make your machine visible over the network to interested
parties.
  
  
+ == Creating Patches for attachment to JIRA issues ==
  
- == Creating Patches for attachment to JIRA ==
- 
- Assuming your trunk repository is in sync with the apache projects, you can use {{{git diff}}}
to create a patch file.
+ Assuming your trunk repository is in sync with the Apache projects, you can use {{{git diff}}}
to create a patch file.
  First, have a directory for your patches:
  {{{
  mkdir ../outgoing
@@ -162, +163 @@

  }}}
  It is essential that patches for JIRA issues are generated with the {{{--no-prefix}}} option.
Without that an extra directory path is listed, and the patches can only be applied with a
{{{patch -p1}}} call, ''which Hudson does not know to do''. If you want your patches to take,
this is what you have to do. You can of course test this yourself by using a command like
{{{patch -p0 << ../outgoing/HDFS-775.1}}} in a copy of the SVN source tree to test that
your patch takes.
  
- If you have checked in your patch, then you need to refer to the patch by name (SHA1 checksum,
and that of the preceeding patch. If it was the last patch and nothing else changed, this
is easy.
+ If you have checked in your patch, then you need to refer to the patch by name (SHA1 checksum),
and that of the preceeding patch. If it was the last patch and nothing else changed, this
is easy.
  {{{
  git diff --no-prefix HEAD~1 HEAD
  }}}

Mime
View raw message