[Couchdb Wiki] Update of "Git_At_Apache_Guide" by NoahSlater

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

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

The "Git_At_Apache_Guide" page has been changed by NoahSlater:
http://wiki.apache.org/couchdb/Git_At_Apache_Guide?action=diff&rev1=21&rev2=22

  Be aware that the branch created by a release with GIT always covers the whole repository.
  
  ==== Release Tags with GIT ====
- [Proposal, not yet coordinated]: Since a Tag in GIT is just a name for an existing sha1 commit, we can treat release tags much more elegant than with SVN where this is technically a 'svn copy'.
  
- While doing the release candidate we give it a {projectName}-{versionNr}-rcX tag. After all the voting passes we can now easily apply the final tag name  {projectName}-{versionNr} to this commit since tags are just a 'name' for a given sha1 commit, and the sha1 does not change at all when tagging. If a vote fails, we can just assign a new '-rc2', etc tag.
+ --([Proposal, not yet coordinated]: Since a Tag in GIT is just a name for an existing sha1 commit, we can treat release tags much more elegant than with SVN where this is technically a 'svn copy'.)--
  
+ --(While doing the release candidate we give it a {projectName}-{versionNr}-rcX tag. After all the voting passes we can now easily apply the final tag name  {projectName}-{versionNr} to this commit since tags are just a 'name' for a given sha1 commit, and the sha1 does not change at all when tagging. If a vote fails, we can just assign a new '-rc2', etc tag.)--
+ 
+ Do not tag a release until the vote has passed.
+ 
+ Apache does not issue release candidates in the same way that other projects do. When a regular user sees a release candidate, they think of it as a testing version of the software. If we tag our release artefacts (which may be prepared by anyone, at any time) as release candidates while we vote on them, we are sending the wrong message to anyone who finds that tag in the repository.
+ 
+ Even if we avoid calling them release candidates, all tags live in the same namespace, so we risk confusing our users if we tag the release artefacts we are voting on, as well as the release artefacts we have actually released. We cannot depend on deleting tags that correspond to failed votes either, because Git does not reliably propagate tag deletion to downstream repositories.
+ 
+ In answer to these concerns, vote emails must reference the tree-ish used to prepare the release. Only when the vote passes must you tag that tree-ish. Preferably using the version number alone, as each Git repository corresponds to exactly one project. The resulting tag list in Git is a clean list of every official release, and every downstream repository will be eventually consistent.
+