Difference between revisions of "SourceCode"

From RackTables Wiki
Jump to navigation Jump to search
Line 61: Line 61:
  
 
== submitting work ==
 
== submitting work ==
<pre>
+
In the case of a GitHub fork of RackTables publishing changes is as simple as using [http://git-scm.com/docs/git-push git push]. To merge your changes into the upstream RackTables notify the dev team by any convenient mean (GitGub pull request or email).
# if you have an account
 
svn commit
 
  
# and if you don't
+
In the case of a private repository use a [http://git-scm.com/docs/git-format-patch git format-patch] command to produce a patch and send it to the developers.
svn diff > my-cool-feature.patch
 
# send the patch file by e-mail
 
</pre>
 

Revision as of 16:14, 2 September 2012

SVN repository layout

RackTables repository currently employs a layout, which is quite standard for SVN.

tags
The place for releases. Once a release have been copied here, its files must not be changed (with the only allowed exception of SVN metadata).
trunk
This is where most of unstable commits happen.
branches
Branches are development lines, which can last up to several months, but eventually get deleted anyway (merged into the mainstream or not). A typical branch is "maintenance-0.X.Y", which is the place to commit bugfixes. These bugfixes become available by means of maintenance releases, and risky commits happen and get tested in trunk. Once the next stable line is ready, the old one becomes unmaintained and gets deleted.

getting a working copy of source

# Anyone can read from the repository, but writing requires being a project developer.
svn co https://racktables.svn.sourceforge.net/svnroot/racktables/branches/maintenance-0.19.x/

# Above command is for the maintenance line. For the trunk (see roadmap picture for exact
# difference between two) respective command is:
svn co https://racktables.svn.sourceforge.net/svnroot/racktables/trunk/

editing files

Use your favourite editor. Please consider existing code style: the default is to keep with Allman style (not with K&R, as was mistakenly stated here before). Indentation is always performed with tabs, please use any tab width you are comfortable with.

Here is an example of a function:

// take port list with order applied and return uplink ports in the same format
function produceUplinkPorts ($domain_vlanlist, $portlist)
{
	$ret = array();
	$employed = array();
	foreach ($domain_vlanlist as $vlan_id => $vlan)
		if ($vlan['vlan_type'] == 'compulsory')
			$employed[] = $vlan_id;
	foreach ($portlist as $port_name => $port)
		if ($port['vst_role'] != 'uplink')
			foreach ($port['allowed'] as $vlan_id)
				if (!in_array ($vlan_id, $employed))
					$employed[] = $vlan_id;
	foreach ($portlist as $port_name => $port)
		if ($port['vst_role'] == 'uplink')
		{
			$employed_here = array();
			foreach ($employed as $vlan_id)
				if (matchVLANFilter ($vlan_id, $port['wrt_vlans']))
					$employed_here[] = $vlan_id;
			$ret[$port_name] = array
			(
				'vst_role' => 'uplink',
				'mode' => 'trunk',
				'allowed' => $employed_here,
				'native' => 0,
			);
		}
	return $ret;
}

viewing local changes

git status

submitting work

In the case of a GitHub fork of RackTables publishing changes is as simple as using git push. To merge your changes into the upstream RackTables notify the dev team by any convenient mean (GitGub pull request or email).

In the case of a private repository use a git format-patch command to produce a patch and send it to the developers.