Gitorious Commands

what is gitorious

Gitorious is the name of a web based project host for collaborative opensource projects using the  Git[Fast Version control system]

 Gitorious provides projects with wikis, a web interface for merge requests and code reviews, and activity timelines for projects and developers

http://gitorious.org/about About - Gitorious] 

Git Common Commands

 . Create a repository in the current directory

git init

. Create a local copy of a git repository

git clone [user@domain:/path]

. View the log

git log

. View log with ASCII graph

git log –stat

. View log with diffs

git log –p

. View branches

git branch

. View all branches

git branch –a

. Create a branch

git branch [branch_name]

. Delete branch

git branch -d [branch_name]

. Force delete a branch

git branch -D [branch_name]

. Create a tracking branch

git branch --track [branch_name] [repo/branch]

. Switch to a branch

git checkout [branch_name]

. Create and switch to a branch

git checkout -b [branch_name]

. Add all content to the index

git add .

. Add specific content to the index

git add [file_name]

. Save changes queued to the index

git commit

. Save all uncommitted changes

git commit –a

. Commit and show diff of changes

git commit –v

. Quick commit message

git commit -m "Message"

. Restart branch with code in another branch

git rebase [branch_name]

. View the difference between branches

git diff [branch1] [branch2]

. Combine code from a branch into the current one

git merge [branch_name]

. Undo last commit or merge

git reset --hard ORIG_HEAD

. Save uncommitted changes

git stash "Description"

. Show stash

git stash list

. Merge the stash with working directory

git stash apply

. Delete stashed code

git stash clear

. Send commit objects to another repository

git push

. Send commits to a specific repo and branch

git push [repository] [branch_name]

. Fetch objects and merge with current branch

. (if tracking)

git pull

. Fetch and merge from a specific repo and branch

git pull [repository] [branch_name]

. Get objects from a repository

git fetch [repository]

. Create a git repository based on a Subversion repo

git-svn clone [url]

. Send git commits back to Subversion

git-svn dcommit

[1]

. Get changes from Subversion

git-svn rebase

 How do I share my local Git repository at Gitorious.org?

Easiest way is to put something like the following in your .git/config file of the repository you wish to push:

[remote "origin"]

       url = git@gitorious.org:project/repository.git

       fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]

       remote = origin

       merge = refs/heads/master

and then git push origin master to push the code to Gitorious.

You can also just run "git push git@gitorious.org:tumbline/mainline.git", or you can setup a remote by doing the following (add --fetch to the add call to get the config from above):

  git remote add origin @gitorious.org:project/repository.git

  # to push the master branch to the origin remote we added above:

  git push origin master

  # after that you can just do:

  git push

---

[1]

Scrum Terminology

Stakeholders
Stakeholders have investment in the product being developed, but are not directly related to the development of the product. Stakeholders make up the Customer Team that provides input into the product backlog.

Product Owner
A single person who has the final authority representing the customer's interest in prioritizing and answering questions about stories. This person must be available to the team at any time, but especially during the Sprint Planning Meeting and the Sprint Review.
on-site customer and stakeholder representative are also the terms for product owner

Acceptance Test
An acceptance test is a test that verifies that the story respects the Product Owner acceptance criteria. These acceptance criteria should be included with each story as early as possible in a Sprint, or before taking the story in sprint is ideal. Using acceptance criteria is essential to confirm a team-wide understanding of each story. For teams who have automated testing setup, it is recommended to automate the acceptance test cases so that the status of the story can be verified anytime in the future by simply running its acceptance test.

Agile Modeling (AM)
Agile Modeling is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices. At a more detailed level AM is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner.

Burn-down Charts
Burn-down Charts show work remaining over time (work remaining is the Y axis and time is the X axis).Burn-down can be charted for the story points remaining in a release (see Release Burn-down) or hours remaining in a sprint (see Sprint Burn-down). Displaying burn-down charts in the team area provides high visibility of progress to the team and its stakeholders."

Continuous Integration [CITA]
A fully automated build and test process that allows a team to build and test their software many times a day on a shared code stream.

Daily Scrum
A short daily meeting where each team members stands and answers the three questions:
1. What have I done for the sprint since the last Scrum meeting?
2. What will I do for the sprint before the next Scrum meeting?
3. What impediments are preventing me from performing work for the sprint as efficiently as possible?
All side discussions should be tabled until after the meeting.
Anyone can attend the daily scrum meeting, but the meeting should be focused on the work of the sprint team.

Epic [A Large Story]
A Story that is too large or complex to be estimated. Before scheduling for a sprint, such large stories should be broken down into smaller sub stories, some of which may also have to be broken down further. The hierarchical relationships among the sub stories that result from repeated breakdowns is valuable because it provides product context for each sub story and allows progress on the entire epic to be tracked.

Impediment
Anything that prevents a team member or the team as a whole from performing work as efficiently as possible is an impediment. The Scrum Master is typically responsible for clearing impediments.

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Operational Backlog
The Operational Backlog, or Parking Lot, is contains the work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code re-factoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc. When pulling work for a sprint, balance the work in the Product Backlog with the work in the Operational Backlog.

Product Backlog
The Product Backlog is the as yet unfulfilled customer requirements, expressed as a prioritized list of stories. Although there are multiple sources of inputs to the Product Backlog, it is the sole responsibility of the Product Owner to prioritize the Product Backlog.

Pair Programming
When two team members work on a programming task together. The driver role implements the code while the navigator role identifies potential issues, enforces standards, and anticipates next steps. The team members should alternate roles frequently. Pair programming has been shown to increase quality, and thereby eventually pay for itself in future productivity. Pair programming also reduces the impact of losing a developer, because the people who paired with him/her have acquired much of his/her knowledge. Pair programming is also a valuable technique for bringing a new developer up to speed more quickly.
Potentially Shippable Product Increment
Software with sufficient quality and utility to be potentially shippable. Each sprint should deliver a potentially shippable product increment. This has two consequences
1. Quality – Untested software is not potentially shippable, so the software produced in each sprint must be fully tested.
2. Utility – Unusable software is not potentially shippable. Implementing horizontal slices of stories will lead to sprint deliveries with functionality that cannot yet be used because the slices could not be delivered for every architectural component in the same sprint. On the other hand, implementing vertical slices will make the functionality delivered by every story in every sprint potentially usable, at least for some user scenarios.

Re-factoring
Systematic transformations that change the structure of code without changing its execution behavior. It is recommended that the code being re factored is well covered by automated Unit Tests - the higher your unit test coverage, the more likely that you will discover when a re factoring inadvertently changes the behavior of an object. Re-factoring is useful for retrofitting design patterns into code when the implementation of new stories would tend to violate Once And Only Once or other design principles.

Release
The transition of a potentially shippable product increment from the development team into routine use by end customers. Releases typically happen when one or more Sprints has resulted in the product having enough value to outweigh the cost to deploy it. Releases can also be used as milestones in the development of a product - these are generally call internal releases.

Release Backlog
The Release Backlog is a subset of the Product Backlog assigned to a specific release for a specific time period. It can be represented as a line in the Product Backlog, or as a separate backlog artifact.

Release Burn-down Chart
The Release Burn-down Chart presents the progress of a release by showing how many story points of work has been done and how many are left to do in the release at the beginning of each Sprint. Note that the total number of story points in a release is not necessarily constant over the lifetime of the release.

Scrum Master
The Scrum Master is a facilitator for the team. Rather than manage the team, the Scrum Master works to assist the team in the following ways:
• Help the Product Owner drive development in order to maximize ROI.
• Facilitate team creativity and empowerment.
• Remove impediments.
• Drive improvements to the process, engineering practices and tools.
• Keep information about the team's progress up to date and visible to all parties.

Scrum of Scrums
A Scrum of Scrums is a team of compose of one or more Team Members of regular Scrum teams. The usual purpose of a Scrum of Scrums is to identify, track, and resolve dependency issues across the represented teams.

Spike
When a story cannot be accurately estimated due to a lack of knowledge (rather than sheer size like an epic), a common approach is to define a story for attaining the knowledge required to provide a good estimate. Such a story is a spike.

Sprint
An iteration of work during which a potentially shippable product increment is implemented. Currently, the recommended practice is 2-weeks.

Sprint Backlog
The set of Stories from the Product Backlog that the team has committed to complete during the Sprint.

Sprint Burn-down Chart
A Sprint Burn-down Chart depicts the total task hours remaining per day. This shows you where the team stands regarding completing the Sprint Backlog. The X-axis represents days in the Sprint, while the Y-axis is estimate hours of effort remaining.

Sprint Planning Meeting
The Sprint Planning Meeting is where the team negotiates with the Product Owner what they will commit to doing in the next Sprint.
The team generally proceeds as follows
1. Determine how many work hours each member will be available during the Sprint.
2. Select stories from the Product Backlog in the order determined by the Product Owner,
3. Break each story into tasks, and
4. Estimate how many hours it will take to complete each task,
5. Repeat steps 2 through 4 until the cumulative number of task hours gets as close to the total available work hours as the team is comfortable committing to.
Breaking the stories into tasks often requires asking the Product Owner clarifying questions. Sometimes, the team can suggest changes in which stories are selected for a sprint to the Product Owner which will make implementation easier."

Sprint Retrospective
The Sprint Retrospective is held at the end of every Sprint after the Sprint Review. The Team Members and Scrum Master meet to discuss what went well and what to improve in the next Sprint.

Sprint Review
The Sprint Review is where the Team Members demonstrate the software that they produced during the Sprint to the Product Owner and Stakeholders. Feedback is welcome, but since the meeting is usually constrained to an hour or less, detailed discussions should be tabled until after the meeting. Note that software completed days before the Sprint Review can and should be demonstrated to the Product Owner and interested Stakeholders earlier in order to be able to negotiate acceptance criteria.

Sprint Task
A Sprint Task (or Task) is a standalone unit of work needed to complete a storie, generally estimated to take between 1 and 18 hours. Team Members select their own tasks. They update the estimated number of hours remaining on each of their tasks on a daily basis. The Sprint Burndown Chart displays the sum of all the updated estimated hours each day.

Stakeholder
A Stakeholder is a person or another team who has an interest in some or all of the Stories that a team is implementing, but is not the Product Owner.

Story
A Story is a customer requirement expressed in the form: "As a , I want so that ." A story should be small enough to estimate its size, comfortably implement in a Sprint and have a single priority.

Story Points
Relative estimate of size of a Story. A recommended practice is to use Fibonacci Numbers or powers of 2 to avoid trying to estimate too finely.

Team Member
Anyone working on any Sprint Tasks. Typically includes developers, testers, documentors. Technical Debt Technical Debt is the difference between doing something the "right-way" versus getting it released quickly. This must be minimized. Minimal technical debt is the single most important factor in delivering a maintainable system. Keeping technical debt to a minimum and re-factoring (below) creates a system that is easier to change and is responsive to customer needs. Technical Debt may be prioritized in the Operational Backlog.

Test Coverage
The percentage of the code which is executed by at least one automated unit test. Usually measured as the percentages of lines of code.
Test Driven Development (TDD)
A programming technique where you:
1. Write a unit test for a class,
2. Make sure the unit test fails,
3. Write the most straight forward, principled code to make that unit test pass,
4. Repeat step 1 through 3 above until the suite of unit tests form a satisfactory specification of the class.

Unit Test
An automated test that verifies a single responsibility of a single unit of code.

Velocity
Velocity is a history-based estimate of how many Story Points a team can complete in one Sprint.
velocity is usually estimated by averaging the number of Story Points the team completed over the last several sprints. Once the velocity for a team stabilizes, the velocity can be used to forecast release and product completion dates, assuming that both the team composition and the number of story points in the releases also remain stable.

The Classic Story of the Pig and Chicken

Here
Pig roles are considered core team members. Performers. People who “do” work
The roles of both Product Owner and the Scrum-Master are considered to be pigs in the team instead of chicken.
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource.

SCP&SSH to the Qemu runtime

MADDE stands for Maemo Application Development and Debugging Environment and offers the following features:


Command-line cross-compiling
Multi-platform support (Linux (32-bit/64-bit), Windows, Mac OS X)
Configurable for different targets & toolchains
Client for the device to simplify the development process


Mad is frontend to madde execution environment. 
Usage: mad [-t TARGET] COMMAND [args]
 COMMAND may be one of the internals listed below
 or system command (such as 'make')


  remote     command set to handle runtime
  info       print madde configuration in xml format
  query      query variables
  list       list components in cross-compilation environment
  set        set default target
  pscreate   create project skeleton


you can scp to the Qemu runtime using the following commands
The ssh port for Qemu is 6666.


"scp -P 6666 filename developer@localhost:/home/developer/ "
 (or) you can do 
"mad remote send  "filename"  "for copying files into Qemu
"mad remote remove "filename" " for deleting files from Qemu
"mad remote install" will install DEBIAN_PACKAGE on runtime
"mad remote uninstall" will uninstall DEBIAN_PACKAGE on runtime   


"ssh -p 6666 developer@localhost"  for logging into Qemu


Here notice the difference, 
for ssh use "-p" (lowercase)for scp use "-P"(highercase)


"mad remote poweron" , "mad remote poweroff "
will turn qemu on and off 


"mad remote shell" opens a login shell on Qemu runtime
"mad ping shell"  checks if Qemu runtime is up and connectable


"mad info"
Prints madde configuration to stdout. The output is in xml format based on schema documented in madinfo.xsd.


"mad list"  will list the components i.e all the targets and runtimes in cross-compilation environment
"mad set"  will set default target.

Accounts & SSO

Accounts & SSO(Single Sign On) Framework

The Concept of  “unified account model”

The Accounts & SSO (Single Sign On) project provides a framework to implement a unified account management system with secure authentication functionality. The account and SSO subsystems are orthogonal, in a sense that they can be used independently of each other. 
Both come with C and C++

Through C (glib/GObject based) and C++ (Qt based) APIs for client applications.

Accounts(How Meego will handle account settings)

Firefox, Thunderbird, Empathy/Pidgin, F-Spot Picasa export plugin: different applications asking for the same data, your Google account settings. The Accounts framework introduced in MeeGo aims at simplifying this situation, allowing application writers to rely on a unified solution for storing/managing accounts settings.

A centralized accounts UI is used to create accounts and edit their settings, while applications are just left with the task of enumerating existing accounts and using them.

SSO(Single Sign On)

A system for centrally storing authentication credentials and handling authentication on behalf of applications as requested by applications. This is a not only a centralized secure password storage; it’s also a framework of authentication plugins which help applications to login to remote servers while preserving user credentials from being exposed to the application.

Overview of "Accounts framework"

The accounts subsystem provides a storage solution for user accounts. Applications which need to store and access user settings for the service they provide over a user account will use the Accounts API. All applications acting on user accounts (such as instant messaging, e-mail, calendar and social networking applications) can benefit of the unified account model provided by this framework.

Design of the possible UI for Unified Account Model

This framework makes it possible to have only one account UI for creating and editing all user accounts; instead of configuring part of the user’s Google (for instance) account in Thunderbird (for e-mail), Empathy or Pidgin (for IM), F-Spot (for photo/video sharing), etc., we'd like to offer the user the possibility to have all of an account’s settings in a single place, divided by sections specific to every service type.

So, we'd have one section with all the settings that are global for the account: username, password (although for password storing we'd recommend using the SSO framework, and just store the ID of the credentials in the accounts DB), display name, maybe avatar, and a switch to enable/disable the account.

Then, every service provided by the account would add its own settings (if any); for sure there should be a switch to toggle the service on/off, plus any settings that makes sense for the service. For instance, the image sharing section could contain a setting for the maximum image resolution to be used when uploading.
These service-specific sections could be implemented via dynamically loadable plugins, or constructed at run time from XML descriptions.

This account UI could be in the control panel of the device, but it could also offer some IPC so that applications could invoke it for configuring a specific service type; for instance, e-mail application could have a menu item “Edit e-mail accounts” which would bring a view of all the accounts providing the e-mail service, and only the e-mail sections of each account could be shown.

Signond single signon daemon

Single Signon Daemon development files Single Signon Daemon provides password storage and credential retrieving service for applications. Provides authentication plugins for passwords and NokiaAccount. 

Casting

 Casting Operators

There are several casting operators specific to the C++ language. These operators are intended to remove some of the ambiguity and danger inherent in old style C language casts. These operators are:

·         dynamic_cast   Used for conversion of polymorphic types.

·         static_cast   Used for conversion of nonpolymorphic types.

·         const_cast   Used to remove the const, volatile, and __unaligned attributes.

·         reinterpret_cast   Used for simple reinterpretation of bits.

·         safe_cast    Used to produce verifiable MSIL.

Use const_cast and reinterpret_cast as a last resort, since these operators present the same dangers as old style casts. However, they are still necessary in order to completely replace old style casts.

const_cast Operator

const_cast < type-id > ( expression )

 

A pointer to any object type or a pointer to a data member can be explicitly converted to a type that is identical except for the const, volatile, and __unalignedqualifiers. For pointers and references, the result will refer to the original object. For pointers to data members, the result will refer to the same member as the original (uncast) pointer to data member. Depending on the type of the referenced object, a write operation through the resulting pointer, reference, or pointer to data member might produce undefined behavior.

You cannot use the const_cast operator to directly override a constant variable's constant status.

The const_cast operator converts a null pointer value to the null pointer value of the destination type.

#include

using namespace std;

class CCTest {

public:

   void setNumber( int );

   void printNumber() const;

private:

   int number;

};

void CCTest::setNumber( int num ) { number = num; }

void CCTest::printNumber() const {

   cout << "\nBefore: " << number;

   const_cast< CCTest * >( this )->number--;   ****

   cout << "\nAfter: " << number;

}

int main() {

   CCTest X;

   X.setNumber( 8 );

   X.printNumber();

}

**** -- Here the const_cast, the data type of the this pointer is const CCTest *. The const_cast operator changes the data type of the this pointer toCCTest *, allowing the member number to be modified. The cast lasts only for the remainder of the line on which it appears.

dynamic_cast Operator

dynamic_cast < type-id > ( expression )

class B { };

class C : public B { };

class D : public C { };

void f(D* pd) {

   C* pc = dynamic_cast(pd);   // ok: C is a direct base class

                                   // pc points to C subobject of pd 

   B* pb = dynamic_cast(pd);   // ok: B is an indirect base class

                                   // pb points to B subobject of pd

}

This type of conversion is called an "upcast" because it moves a pointer up a class hierarchy, from a derived class to a class it is derived from. An upcast is an implicit conversion.

If type-id is void*, a run-time check is made to determine the actual type of expression. The result is a pointer to the complete object pointed to by expression. For example:

class B {virtual void f();};

class D : public B {virtual void f();};

void f() {

   B* pb = new D;   // unclear but ok

   B* pb2 = new B;

   D* pd = dynamic_cast(pb);   // ok: pb actually points to a D

   D* pd2 = dynamic_cast(pb2);   // pb2 points to a B not a D

}

This type of conversion is called a "downcast" because it moves a pointer down a class hierarchy, from a given class to a class derived from it.

In cases of multiple inheritance, possibilities for ambiguity are introduced. Consider the class hierarchy shown in the following figure.

For CLR types, dynamic_cast results in either a no-op if the conversion can be performed implicitly, or an MSIL isinst instruction, which performs a dynamic check and returns nullptr if the conversion fails.

static_cast Operator

static_cast  ( expression ) 

converts expression to the type of type-id based solely on the types present in the expression. No run-time type check is made to help ensure the safety of the conversion.

The static_cast operator can be used for operations such as converting a pointer to a base class to a pointer to a derived class. Such conversions are not always safe.

In general you use static_cast when you want to convert numeric data types such as enums to ints or ints to floats, and you are certain of the data types involved in the conversion. static_cast conversions are not as safe as dynamic_cast conversions, because static_cast does no run-time type check, while dynamic_cast does. Adynamic_cast to an ambiguous pointer will fail, while a static_cast returns as if nothing were wrong; this can be dangerous. Although dynamic_cast conversions are safer, dynamic_cast only works on pointers or references, and the run-time type check is an overhead. See dynamic_cast for more details.

class B {

public:

   virtual void Test(){}

};

class D : public B {};

void f(B* pb) {

   D* pd1 = dynamic_cast(pb);

   D* pd2 = static_cast(pb);

}

The static_cast operator can also be used to perform any implicit conversion, including standard conversions and user-defined conversions

typedef unsigned char BYTE;

void f() {

   char ch;

   int i = 65;

   float f = 2.5;

   double dbl;

   ch = static_cast(i);   // int to char

   dbl = static_cast(f);   // float to double

   i = static_cast(ch);

}

reinterpret_cast Operator

reinterpret_cast < type-id > ( expression )

The reinterpret_cast operator also allows any integral type to be converted into any pointer type and vice versa. Misuse of the reinterpret_cast operator can easily be unsafe. Unless the desired conversion is inherently low-level, you should use one of the other cast operators.

The reinterpret_cast operator can be used for conversions such as char* to int*, or One_class* to Unrelated_class*, which are inherently unsafe.

The result of a reinterpret_cast cannot safely be used for anything other than being cast back to its original type. Other uses are, at best, nonportable.

The reinterpret_cast operator cannot cast away the const, volatile, or __unaligned attributes. See const_cast Operator for information on removing these attributes.

The reinterpret_cast operator converts a null pointer value to the null pointer value of the destination type.

One practical use of reinterpret_cast is in a hash function, which maps a value to an index in such a way that two distinct values rarely end up with the same index.

#include 

// Returns a hash code based on an address

unsigned short Hash( void *p ) {

   unsigned int val = reinterpret_cast( p );

   return ( unsigned short )( val ^ (val >> 16));

}

using namespace std;

int main() {

   int a[20];

   for ( int i = 0; i < 20; i++ )

      cout << Hash( a + i ) << endl;

}

The reinterpret_cast allows the pointer to be treated as an integral type. The result is then bit-shifted and XORed with itself to produce a unique index (unique to a high degree of probability). The index is then truncated by a standard C-style cast to the return type of the function.

The C++ language provides that if a class is derived from a base class containing virtual functions, a pointer to that base class type can be used to call the implementations of the virtual functions residing in the derived class object. A class containing virtual functions is sometimes called a "polymorphic class."
Since a derived class completely contains the definitions of all the base classes from which it is derived, it is safe to cast a pointer up the class hierarchy to any of these base classes. Given a pointer to a base class, it might be safe to cast the pointer down the hierarchy. It is safe if the object being pointed to is actually of a type derived from the base class. In this case, the actual object is said to be the "complete object." The pointer to the base class is said to point to a "subobject" of the complete object. For example, consider the class hierarchy shown in the following figure.

Conditional Compilation

. They include #if, #elif, #else, #ifdef, and #ifndef. An #if or #if/#elif/#else block or a #ifdef or #ifndef block must be terminated with a closing #endif. 

#if 0
/* comment ...
*/

// code

/* comment */
#endif

Avoiding Including Files Multiple Times (idempotency)

#ifndef _FILE_NAME_H_
#define _FILE_NAME_H_

/* code */

#endif // #ifndef _FILE_NAME_H_

#ifndef

#ifndef 
/* code */
#else
/* code to include if the token is defined */
#endif

#ifndef checks whether the given token has been #defined earlier in the file or in an included file; if not, it includes the code between it and the closing #else or, if no #else is present, #endif statement. #ifndef is often used to make header files idempotent by defining a token once the file has been included and checking that the token was not set at the top of that file.

#ifndef _INCL_GUARD
#define _INCL_GUARD
#endif

#define SWAP(a, b)  {a ^= b; b ^= a; a ^= b;} 

Multiline macros
For instance, we could rewrite swap as
#define SWAP(a, b)  {                   \
                        a ^= b;         \
                        b ^= a;         \ 
                        a ^= b;         \
                    }