Developers Guide
Table of Contents
This is the developer guide of SCORE Lab
How to use SVN
Checkout
Out side the directory;
svn checkout http://192.248.16.125/svn/<project>/trunk <project> --username user_name
Adding file
Inside the directory;
svn add file_or_dir_name
Delete file
Inside the directory;
svn delete file_or_dir_name
Commit
Inside the directory;
svn commit -m "Message" . --username user_name
Creating trunk
svn mkdir -m "Message" http://192.248.16.125/svn/<project>/trunk
Importing project
svn import -m "Message" <project> http://192.248.16.125/svn/<project>/trunk
Creating a tag
svn copy http://192.248.16.125/svn/<project>/trunk http://192.248.17.223/svn/<project>/tags/release-<version> -m "Message"
Creating a branch
svn copy http://192.248.16.125/svn/<project>/trunk http://192.248.16.125/svn/<project>/branches/<branch_name> -m "Message"
Remarks
Trunk: Main development area. This is where your next major release of the code lives, and generally has all the newest features.
Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.
Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code.
Source Patching
Create patch
Assume Original source code at folder SOURCE_O, and modified source code at folder SOURCE_N. And there have multiple sub directories at SOURCE_O and SOURCE_N too.
diff -urBN SOURCE_O SOURCE_N > <patch_name>-<patch_version>.patch
-u Unified format (Format of the patch file) -r Recursive (Multiple levels directories) -B Ignore Blank Lines -N Include New Files
Apply Patch
First cd into the new directory (the one to be patched). Please do a dry-run before really patch it. Bare in mind, patch will be working very specifically. Let say the version my_patch-1.2.patch is use to patch SOURCE_O_1.0, if you apply patch on SOURCE_O_2.0, sometimes it will corrupt your source code. So, to make sure it works, do a dry run. Dry-run means a fake-test.
Doing dry-run:
patch --dry-run -p1 -i <patch_name>-<patch_version>.patch
Patching for real:
patch -p1 -i <patch_name>-<patch_version>.patch
Removing patch(if required):
patch -p1 -R -i <patch_name>-<patch_version>.patch
--dry-run Fake (not appling really) -p1 Patch level ( Level of the present working directory with respect to the project root ) -i Patch file -R Remove patch
Coding standard
/**
* \defgroup coding-style Coding style
*
* This is how a Doxygen module is documented - start with a \defgroup
* Doxygen keyword at the beginning of the file to define a module,
* and use the \addtogroup Doxygen keyword in all other files that
* belong to the same module. Typically, the \defgroup is placed in
* the .h file and \addtogroup in the .c file.
*
* @{
*/
/**
* \file
* A brief description of what this file is.
* \author
* Adam Dunkels
*
* Every file that is part of a documented module has to have
* a \file block, else it will not show up in the Doxygen
* "Modules" * section.
*/
/* Single line comments look like this. */
/*
* Multi-line comments look like this. Comments should prefferably be
* full sentences, filled to look like real paragraphs.
*/
#include "contiki.h"
/*
* Make sure that non-global variables are all maked with the static
* keyword. This keeps the size of the symbol table down.
*/
static int flag;
/*
* All variables and functions that are visible outside of the file
* should have the module name prepended to them. This makes it easy
* to know where to look for function and variable definitions.
*
* Put dividers (a single-line comment consisting only of dashes)
* between functions.
*/
/*---------------------------------------------------------------------------*/
/**
* \brief Use Doxygen documentation for functions.
* \param c Briefly describe all parameters.
* \return Briefly describe the return value.
* \retval 0 Functions that return a few specified values
* \retval 1 can use the \retval keyword instead of \return.
*
* Put a longer description of what the function does
* after the preamble of Doxygen keywords.
*
* This template should always be used to document
* functions. The text following the introduction is used
* as the function's documentation.
*
* Function prototypes have the return type on one line,
* the name and arguments on one line (with no space
* between the name and the first parenthesis), followed
* by a single curly bracket on its own line.
*/
void
code_style_example_function(void)
{
/*
* Local variables should always be declared at the start of the
* function.
*/
int i; /* Use short variable names for loop
counters. */
/*
* There should be no space between keywords and the first
* parenthesis. There should be spaces around binary operators, no
* spaces between a unary operator and its operand.
*
* Curly brackets following for(), if(), do, and case() statements
* should follow the statement on the same line.
*/
for(i = 0; i < 10; ++i) {
/*
* Always use full blocks (curly brackets) after if(), for(), and
* while() statements, even though the statement is a single line
* of code. This makes the code easier to read and modifications
* are less error prone.
*/
if(i == c) {
return c; /* No parentesis around return values. */
} else { /* The else keyword is placed inbetween
curly brackers, always on its own line. */
c++;
}
}
}
/*---------------------------------------------------------------------------*/
/*
* Static (non-global) functions do not need Doxygen comments. The
* name should not be prepended with the module name - doing so would
* create confusion.
*/
static void
an_example_function(void)
{
}
/*---------------------------------------------------------------------------*/
/* The following stuff ends the \defgroup block at the beginning of
the file: */
Editing WIKI
See WikiFormatting for a friendly complete guide of wiki formatting.
Adding a Table of Content(TOC)
TocMacro? plugin will allow to generate a 'Table of Content' for your project wiki.
In your projects admin page you have to enable TocMacro? Plugin to use this feature.
For default case you can use [[TOC]] macro to generate the table of content using headings and sub-headings in it. Read this for more information http://trac-hacks.org/wiki/TocMacro.
Adding Images
First Upload the file using 'attach file' button and then use [[Image(image_name.ext)]] macro to place it in wiki.
eg:[[Image(logo-190.png)]]
Changing the Theme
Goto Admin > Plugins You can find 'TracCrystalXTheme 1.0' and 'TracThemeEngine? 2.0.1' Plugins there. Enable 'TracCrystalXTheme 1.0' and 'TracThemeEngine? 2.0.1'. This will give you a new menu entry called 'Theme' Goto 'Theme' and select the theme there. and it will apply.
Installing new plugins to your Trac project
You can find many plugins from http://trac-hacks.org. Download the required plugin say, plugin.zip. Goto Admin and upload the plugin and install.
Embed flash in wiki
Goto Admin and enable TracFlashEmbedMacro?
Embed YouTube? or Vimeo
[[Embed(youtube=emYqURahUKI)]] [[Embed(vimeo=3840952,w=400,h=300)]]
Embed SWF by url
[[Embed(swf=http://trac-hacks.org/attachment/wiki/FlashEmbedMacro/flowers.swf?format=raw,w=500,h=400)]] [[Embed(swf=/attachment/wiki/FlashEmbedMacro/flowers.swf?format=raw,w=500,h=400)]]
Embed SWF from attachment
[[Embed(swf=flowers.swf,w=500,h=400)]] [[Embed(swf=attachment:flowers.swf,w=500,h=400)]]
More info: http://trac-hacks.org/wiki/FlashEmbedMacro
Attachments
- logo-190.png (9.2 kB) - added by nayanajith 5 months ago.
