<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!--
#msg dl { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt;  }
#msg dl a { font-weight: bold}
#msg dl a:link    { color:#fc3; }
#msg dl a:active  { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre, #msg p { overflow: auto; background: #ffc; border: 1px #fc0 solid; padding: 6px; }
#msg ul { overflow: auto; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff  {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<title>[31680] trunk/base/HACKING</title>
</head>
<body>

<div id="msg">
<dl>
<dt>Revision</dt> <dd><a href="http://trac.macosforge.org/projects/macports/changeset/31680">31680</a></dd>
<dt>Author</dt> <dd>jberry@macports.org</dd>
<dt>Date</dt> <dd>2007-12-02 16:24:31 -0800 (Sun, 02 Dec 2007)</dd>
</dl>

<h3>Log Message</h3>
<pre>Hard wrap and detab HACKING file. Whitespcae changes only.</pre>

<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkbaseHACKING">trunk/base/HACKING</a></li>
</ul>

</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkbaseHACKING"></a>
<div class="modfile"><h4>Modified: trunk/base/HACKING (31679 => 31680)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/base/HACKING        2007-12-03 00:17:18 UTC (rev 31679)
+++ trunk/base/HACKING        2007-12-03 00:24:31 UTC (rev 31680)
</span><span class="lines">@@ -1,35 +1,72 @@
</span><span class="cx"> # Project naming and copyright attribution:
</span><span class="cx"> 
</span><del>-* &quot;The MacPorts Project&quot; is the string that shall be used whereever there's a need to reference our project name, such as in copyright notices.
-* A developer or contributor is advised to attribute himself a copyright notice if he/she is contributing a full new source file or a full new feature
-  to an already existing source file in the &quot;base&quot; component of our repository.
-* An exception to this rule is our Portfiles, since they are partly meant for human eyes consumption and the boilerplate header comments should be kept
-  down to a minimum
-* A copyright notice attributed to our group name, &quot;The MacPorts Project&quot;, should also be added to these source files (if not already there) if they're
-  being uploaded to the &quot;base&quot; component of our repository, since as such they are being contributed to the project.
</del><ins>+ *  &quot;The MacPorts Project&quot; is the string that shall be used whereever
+    there's a need to reference our project name, such as in copyright
+    notices.
</ins><span class="cx"> 
</span><ins>+ *  A developer or contributor is advised to attribute himself a copyright
+    notice if he/she is contributing a full new source file or a full
+    new feature to an already existing source file in the &quot;base&quot;
+    component of our repository.
</ins><span class="cx"> 
</span><ins>+ *  An exception to this rule is our Portfiles, since they are partly
+    meant for human eyes consumption and the boilerplate header comments
+    should be kept down to a minimum
+
+ *  A copyright notice attributed to our group name, &quot;The MacPorts
+    Project&quot;, should also be added to these source files (if not already
+    there) if they're being uploaded to the &quot;base&quot; component of our
+    repository, since as such they are being contributed to the project.
+
+
</ins><span class="cx"> # Commits to the &quot;base&quot; component of the repository:
</span><span class="cx"> 
</span><del>-* Commits with user-visible affect made to the &quot;base&quot; component of the repository should be accompanied by a corresponding entry in the base/ChanegeLog file,
-  with references to pertitent Trac ticket numbers and svn commit revisions where appropriate.
-* Such entries to the ChangeLog need not be full duplications of their related commit logs if the latter are thorough explanations of what's involved in the commit.
-  In such cases it's perfectly acceptable to enter just a summary of the commit and point the reader to further information through the related svn revision
-  and Trac ticket number (if applicable).
-* Related commits to &quot;base&quot; should be grouped in a single ChangeLog entry.
-* Commits to &quot;base&quot; need not update the base/NEWS file, as such will be constructed with the relevant information at MacPorts release time by the release engineers.
</del><ins>+ *  Commits with user-visible affect made to the &quot;base&quot; component of the
+    repository should be accompanied by a corresponding entry in the
+    base/ChanegeLog file, with references to pertitent Trac ticket
+    numbers and svn commit revisions where appropriate.
</ins><span class="cx"> 
</span><ins>+ *  Such entries to the ChangeLog need not be full duplications of their
+    related commit logs if the latter are thorough explanations of
+    what's involved in the commit. In such cases it's perfectly
+    acceptable to enter just a summary of the commit and point the
+    reader to further information through the related svn revision and
+    Trac ticket number (if applicable).
</ins><span class="cx"> 
</span><ins>+ *  Related commits to &quot;base&quot; should be grouped in a single ChangeLog
+    entry.
+
+ *  Commits to &quot;base&quot; need not update the base/NEWS file, as such will be
+    constructed with the relevant information at MacPorts release time
+    by the release engineers.
+
+
</ins><span class="cx"> # Whitespace rules as discussed on the development list (macports-dev):
</span><span class="cx"> 
</span><del>-* All source code files MUST use soft tabs at a tabstop of 4. No hard tabs are allowed.
-* All source code files SHOULD have the following as the first line of the file:
-    # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
-  This is a modeline that works for both emacs and vim.
-* Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation of this is left up to the discretion of the maintainer.
-* Portfiles SHOULD use the given modeline
-* Makefiles MUST use tabs as it is required by the syntax. Makefiles SHOULD use a tab stop of 8.
-* Makefiles MAY use a modeline. The following works for emacs and vim:
-    # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
-* All other files (documentation, etc) SHOULD use soft tabs at a tabstop of 4 if the document format allows.
-* All other files (documentation, etc) SHOULD NOT use a modeline as it is probably meant for human consumption.
</del><ins>+ *  All source code files MUST use soft tabs at a tabstop of 4. No hard
+    tabs are allowed.
+
+ *  All source code files SHOULD have the following as the first line of
+    the file:
+        
+        # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
+        
+    This is a modeline that works for both emacs and vim.
+    
+ *  Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation
+    of this is left up to the discretion of the maintainer.
+
+ *  Portfiles SHOULD use the given modeline
+
+ *  Makefiles MUST use tabs as it is required by the syntax. Makefiles
+    SHOULD use a tab stop of 8.
+
+ *  Makefiles MAY use a modeline. The following works for emacs and vim:

+        # -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:filetype=Makefile:noet:sw=8:ts=8
+
+ *  All other files (documentation, etc) SHOULD use soft tabs at a tabstop
+    of 4 if the document format allows.
+
+ *  All other files (documentation, etc) SHOULD NOT use a modeline as it
+    is probably meant for human consumption.
</ins></span></pre>
</div>
</div>

</body>
</html>