Slicer Wiki - User contributions [en]

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-24T16:03:16Z

Sankhesh.jhaveri: /* Development with Git */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

''See also:''[[Slicer:git-svn | Instructions for setting up a git repository to interact with Slicer's svn]]

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
:This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified. 
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). 
NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes. 

Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|align="center"|
[http://www.vtk.org/Wiki/Elisp_Code_for_VTK-Style_C_Indentation <code>Emacs configuration file</code>]
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
:This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

: Examples of ''improper'' commit messages:

Fixed

:This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

:This is too long and defeats the purpose of a Subject line.

: A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
:This is probably because in CVS it is hard to abort a commit if it already brought up the message editor. 
:In Git this is trivial. Just leave the message blank and the whole commit will be aborted. 
:Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>. 

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-24T15:55:39Z

Sankhesh.jhaveri:

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
:This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified. 
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). 
NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes. 

Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|align="center"|
[http://www.vtk.org/Wiki/Elisp_Code_for_VTK-Style_C_Indentation <code>Emacs configuration file</code>]
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
:This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

: Examples of ''improper'' commit messages:

Fixed

:This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

:This is too long and defeats the purpose of a Subject line.

: A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
:This is probably because in CVS it is hard to abort a commit if it already brought up the message editor. 
:In Git this is trivial. Just leave the message blank and the whole commit will be aborted. 
:Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>. 

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-24T15:50:55Z

Sankhesh.jhaveri: /* Slicer Setup */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
:This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified. 
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). 
NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes. 

Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
:This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

: Examples of ''improper'' commit messages:

Fixed

:This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

:This is too long and defeats the purpose of a Subject line.

: A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
:This is probably because in CVS it is hard to abort a commit if it already brought up the message editor. 
:In Git this is trivial. Just leave the message blank and the whole commit will be aborted. 
:Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>. 

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-24T15:48:19Z

Sankhesh.jhaveri: /* commit-msg */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified. 
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). 
NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes. 

Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
:This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

: Examples of ''improper'' commit messages:

Fixed

:This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

:This is too long and defeats the purpose of a Subject line.

: A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
:This is probably because in CVS it is hard to abort a commit if it already brought up the message editor. 
:In Git this is trivial. Just leave the message blank and the whole commit will be aborted. 
:Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>. 

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-24T15:45:02Z

Sankhesh.jhaveri: /* pre-commit */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified. 
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). 
NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes. 

Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/Tutorials

2013-04-24T15:40:31Z

Sankhesh.jhaveri:

How To
----

* [[Documentation/{{documentation/version}}/Developers/Build_Instructions#CHECKOUT_slicer_source_files|Checkout Slicer source]] {{new}}
* [[Documentation/{{documentation/version}}/Developers/DevelopmentWithGit|Setup for Git development]] {{new}}
* [[Documentation/{{documentation/version}}/Developers/Build_Instructions#Git|Commit change sets]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/ContributePatch|Contribute a patch]]
* [[Slicer:git-svn#Integrating_topic_from_external_contributor|Integrate topic from external contributor]]{{new}}
<hr>

* [[Documentation/{{documentation/version}}/Developers/Modules#Command_Line_Interface_.28CLI.29|Create a CLI module or extension]]
* [[Documentation/{{documentation/version}}/Developers/Modules#Loadable_Modules|Create a Loadable module or extension]]
* [[Documentation/{{documentation/version}}/Developers/Modules#Scripted_Modules|Create a Scripted module or extension]]
* [[Documentation/{{documentation/version}}/Developers/EditorExtension|Create an Editor effect]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/BundleModulesIntoExtension|Bundle module(s) into a Slicer extension]] {{updated}}
* [[Documentation/{{documentation/version}}/Developers/Build_Module|Build module outside of Slicer source tree]] {{new}}
<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/SelfTestModule|Write a Self Test Module]] {{new}}
* [[Documentation/{{documentation/version}}/Developers/Tutorials/UploadTestData|Upload test data on Midas]] {{new}}
<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/DocumentModule|Document a module]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/DocumentExtension|Document an extension]]
<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/ObtainExtensionServerApiKey|Obtain an API key to submit on the extension server]] {{updated}}
* [[Documentation/{{documentation/version}}/Developers/Tutorials/BuildTestPackageDistributeExtensions#Upload an extension in the experimental folder|Upload an extension in the experimental folder]]{{new}}
* [[Documentation/{{documentation/version}}/Developers/Tutorials/BuildTestPackageDistributeExtensions#Contribute an extension description file|Contribute an extension description file]]{{new}}

<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/PortingCLIToITKv4|Port a CLI to ITKv4]]{{new}}

<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/QtCreator|Setup QtCreator to develop Slicer application or modules]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/DashboardSetup|Setup a dashboard]]
<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/Debug Instructions|Use debugger with Slicer application]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/Troubleshooting|Troubleshoot issues such as crash, or memory leaks]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/MemoryManagement|Prevent memory leaks]]
<hr>
* [[Documentation/{{documentation/version}}/Developers/Tutorials/WidgetWriting|Write a widget for Slicer and Qt Designer]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/QtDesigner|Use custom widgets in Qt Designer]]
* [[Documentation/{{documentation/version}}/Developers/Tutorials/PythonAndUIFile|Load UI file from python]]
<hr>
* [http://www.na-mic.org/Wiki/index.php/Projects:MATLABSlicerExampleModule Pass data between Slicer and Matlab]{{experimental}}

Documentation/Nightly/Developers/FAQ/General

2013-04-24T15:35:51Z

Sankhesh.jhaveri:

<noinclude>__TOC__
={{#titleparts: {{PAGENAME}} | | -1 }}=</noinclude><includeonly>
='''Developer FAQ: {{{1}}}'''=
</includeonly>

== What is Slicer ? ==

{{:Documentation/{{documentation/version}}/Developers/Slicer}}

== How to setup for Git development ? ==
[[Documentation/{{documentation/version}}/Developers/DevelopmentWithGit#Slicer Setup | Slicer Setup ]]

== How to contribute a patch ? ==
{{:Documentation/{{documentation/version}}/Developers/Tutorials/ContributePatch}}

== What is our bug / feature request workflow ? ==

{{:Documentation/{{documentation/version}}/Developers/IssueWorkflow}}

== How to schedule a Developer Hangout ? ==
See instruction [[Developer_Meetings/OrganizerInstruction|here]]

Developer Meetings/20130416

2013-04-16T17:45:02Z

Sankhesh.jhaveri: /* To discuss */

__TOC__

== To discuss ==
* Presentation of two new extensions by Laurent: http://slicer-devel.65872.n3.nabble.com/Proposition-of-2-new-extensions-tt4028359.html
** PathPlanner: [http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Extensions/PathPlanner wiki] / [https://github.com/SlicerIGT/PathPlanner Source]
** VisuaLine: [http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Extensions/VisuaLine wiki] / [https://github.com/SlicerIGT/VisuaLine Source]
* Presentation of Andriy extension
** DICOMPhilipsRescalePlugin: [http://wiki.slicer.org/slicerWiki/index.php/Documentation/Nightly/Extensions/DICOMPhilipsRescalePlugin wiki]
* DisplayableNode::SetDisplayVisibility crash
** http://slicer-devel.65872.n3.nabble.com/DisplayableNode-SetDisplayVisibility-crash-tt4028238.html
** https://github.com/Slicer/Slicer/blob/7c165bc88bcd24fec807bcc54619616fb0b518b8/Libs/MRML/Core/vtkMRMLDisplayableNode.cxx#L175-191
* Slicer 4.3 release plan
* Review issue targeted for Slicer 4.3
* Git hooks: Ensure Mantis ID is mentioned in commit message? ⇒ https://github.com/sankhesh/Slicer/blob/hooks/commit-msg#L56

== Conclusion ==

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-14T14:40:21Z

Sankhesh.jhaveri: /* Further Work */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided [http://nvie.com/posts/a-successful-git-branching-model/ here].
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-14T14:36:44Z

Sankhesh.jhaveri: moved Documentation/Labs/DevelopmentWithGit to Documentation/Nightly/Developers/DevelopmentWithGit

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Labs/DevelopmentWithGit

2013-04-14T14:36:44Z

Sankhesh.jhaveri: moved Documentation/Labs/DevelopmentWithGit to Documentation/Nightly/Developers/DevelopmentWithGit

#REDIRECT [[Documentation/Nightly/Developers/DevelopmentWithGit]]

Documentation/Nightly/Developers/Tutorials/ContributePatch

2013-04-14T14:35:52Z

Sankhesh.jhaveri:

The following instructions describes the recommended workflow to contribute patch to Slicer code base.

It is assumed you followed the [[Documentation/4.1/Developers/StartHere#New_community_member_checklist|New community member checklist]] and have a clone of https://github.com/Slicer/Slicer/.
It is also assumed that you have setup the development environment as described in the [[Documentation/Nightly/Developers/DevelopmentWithGit#Slicer_Setup | Slicer Setup]] section.

'''If not already done, make sure to read the [[Documentation/{{documentation/version}}/Developers/Style_Guide|Slicer Coding Style Guide]] :-)'''

* 1. Create an issue in the [http://na-mic.org/Mantis/bug_report_page.php tracker]. For example, see issue [http://na-mic.org/Mantis/view.php?id=1906 #1906]

* 2. Make sure your fork has a [https://help.github.com/articles/adding-a-remote git remote]. Replace <code>jcfr</code> with your git login.
<pre>
git remote add jcfr git@github.com:jcfr/Slicer.git
</pre>

* 3. Create a topic named <code><issuer_number>-a-descriptive-topic-name</code>. For example:
<pre>
git checkout -b 1906-uninstall-extensions-on-restart
</pre>

* 4. Add a note to the issue with a link pointing to your topic. For example, see note [http://na-mic.org/Mantis/view.php?id=1906#c4578 1906#c4578]

* 5. Send an email on the [http://massmail.bwh.harvard.edu/mailman/listinfo/slicer-devel slicer-developers] list pointing to the reported bug. Title of the email should start with <code>[BUG <IssueNumber>] Title of the bug - <category></code>

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-14T14:27:51Z

Sankhesh.jhaveri: /* Slicer Setup */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/Build Instructions/CheckoutSourceCode

2013-04-14T14:26:33Z

Sankhesh.jhaveri: /* Git */

== CHECKOUT slicer source files ==

 
1. While it is not enforced, we strongly recommend you to '''AVOID''' the use of '''SPACES''' for both the <code>source directory</code> and the <code>build directory</code>. We mean it.

2. Even if you use <code>svn</code> to check out Slicer source code, you will need to have <code>git</code> installed to checkout and build other libraries. '''YES''', you need to install the things listed in the [[Documentation/{{documentation/version}}/Developers/Build Instructions/Prerequisites|prerequisites]] !.

3. Reading the following page: [[Slicer:git-svn|Slicer guide to <code>git-svn</code>]]

 

=== Git ===

If you plan on contributing code, checking the code using Git and configuring the <code>git-svn</code> bridge is the way to go. See [[Documentation/{{documentation/version}}/Developers/Tutorials/ContributePatch|How to contribute a patch ?]]

* Clone the github repository

git clone git://github.com/Slicer/Slicer.git

* Setup the development environment using the [https://github.com/Slicer/Slicer/blob/master/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>] script as described on our [[Documentation/Nightly/Developers/DevelopmentWithGit | Development With Git]] page.

* Configure the <code>git-svn</code> bridge to ensure the mapping with svn revision.

cd Slicer
git svn init http://svn.slicer.org/Slicer4/trunk
git update-ref refs/remotes/git-svn refs/remotes/origin/master
git checkout master
git svn rebase

=== Svn ===

To simply build Slicer, getting the code using <code>svn</code> is a more straight-forward approach.

svn co http://svn.slicer.org/Slicer4/trunk Slicer

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-14T14:17:56Z

Sankhesh.jhaveri: /* Git */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==


Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.
Git can be obtained as described on our [[Documentation/Nightly/Developers/Git/Download | Git download page]].


Please see our [[Documentation/Nightly/Developers/Git/Resources | Git resource links]] for third party documentation, such as the [http://progit.org/book/ ProGit Book].

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/Git

2013-04-14T14:04:03Z

Sankhesh.jhaveri:

Back to [[Documentation/{{documentation/version}}/Developers|Developers Information]]←

Git is the revision control system that Slicer uses.

*[[Documentation/Nightly/Developers/Git/Download|Git/Download]]
*[[Documentation/Nightly/Developers/Git/Resources|Git/Resources]]

Documentation/Nightly/Developers/Git/Resources

2013-04-14T13:55:00Z

Sankhesh.jhaveri: Created page with 'Additional information about Git may be obtained at these sites: * [http://git-scm.com Git Homepage] * [http://try.github.com GitHub Try Git In Your Browser] * [http://git.wiki.…'

Additional information about Git may be obtained at these sites:

* [http://git-scm.com Git Homepage]
* [http://try.github.com GitHub Try Git In Your Browser]
* [http://git.wiki.kernel.org/index.php/GitDocumentation Git Documentation Wiki]
* [http://book.git-scm.com/ Git Community Book]
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git]
* [http://github.com/guides/git-cheat-sheet Git Cheat-Sheet]
* [http://git-scm.com/book/ Pro Git]
* [http://gitref.org/ Git Reference]
* [http://marklodato.github.com/visual-git-guide/ A Visual Git Reference]
* [http://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model] [http://github.com/downloads/nvie/gitflow/Git-branching-model.pdf PDF]
* [http://pcottle.github.com/learnGitBranching/ LearnGitBranching - Web application designed to help beginners grasp the powerful concepts behind branching]

Documentation/Nightly/Developers/Git/Download

2013-04-14T13:53:25Z

Sankhesh.jhaveri: Created page with '==Generic== Visit the main Git [http://www.git-scm.com/download download site]. ==Windows== Git comes in two flavors on Windows: * A Windows native application installer * A …'

==Generic==

Visit the main Git [http://www.git-scm.com/download download site].

==Windows==

Git comes in two flavors on Windows:

* A Windows native application installer
* A Cygwin package

Choose one and stick with it.
They do not get along well in a given work tree on disk
(the repository formats are compatible but the "stat cache" of the work tree is not unless <code>core.filemode</code> is <code>false</code>).

===MSysGit===

Download the "Full installer for official Git" from [http://code.google.com/p/msysgit/downloads/list here]. You want to download the file that is named something like

Git-1.7.10-preview20120409.exe
''If you notice that the filename has changed (because a new version was released or something similar), please update this wiki!''

Run the installer. When prompted, choose to ''not'' modify the <code>PATH</code> and choose the <code>core.autocrlf=true</code> option.
Launch the "Git Bash" tool to get a command line shell with Git.

===Cygwin===

Install packages:

* '''git''': Git command-line tool
* '''gitk''': Graphical history browser
* '''git-completion''': Bash shell completion rules

Launch a Cygwin command prompt to get a command line shell with Git.

==Mac==

===Xcode 4===

If you have Xcode 4 installed, you already have git installed.

Verify with:

$ which git
/usr/bin/git

$ git --version
git version 1.7.4.4

===OS X Installer===

Download an installer from [http://code.google.com/p/git-osx-installer/ here].

===MacPorts===

Enter these commands:

$ sudo port selfupdate
$ sudo port install git-core +doc

==Linux==

Popular Linux distributions already come with packages for Git.
Typically the packages are called:

* '''git-core''': Git command-line tool
* '''git-doc''': Git documentation
* '''gitk''': Graphical history browser

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-14T13:46:25Z

Sankhesh.jhaveri: /* Testing this setup */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==
[http://www.paraview.org/Wiki/Git/Download Install Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-04-12T16:08:12Z

Sankhesh.jhaveri: /* Downloading Git */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

For now, see the [[Slicer:git-svn| instructions for setting up a git repository to interact with slicer's svn]].

== Git ==
[http://www.paraview.org/Wiki/Git/Download Install Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Testing this setup ==
* You can checkout my branch from [https://github.com/sankhesh/Slicer/tree/2834-consolidate-svn-git-hooks here].
* Once cloned, you can run the SetupForDevelopment script as described above to setup git hooks.
* Kindly review the changes, test the hooks and provide your valuable comments/suggestions.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Developer Meetings/20130402

2013-04-02T17:55:57Z

Sankhesh.jhaveri: /* To discuss */

__TOC__

== To discuss ==

* Build DCMTK shared? http://www.na-mic.org/Bug/view.php?id=3040
* Fiducials are written to a separate file with a "|" delimiter - http://slicer-devel.65872.n3.nabble.com/fcsv-files-tt4028175.html
* CLI's are broken: http://na-mic.org/Mantis/view.php?id=3042
* Take a decision for the Ohloh accounts: Slicer vs Slicer4
* Save/Restore tree state issue: http://www.na-mic.org/Bug/view.php?id=2557
* [[Documentation/Labs/DevelopmentWithGit | Git Development]]
* Screenshot based QtTesting support: http://www.na-mic.org/Bug/view.php?id=2567

== Conclusion ==

Developer Meetings/20130326

2013-03-27T14:20:07Z

Sankhesh.jhaveri: /* Conclusion */

__TOC__

== To discuss ==
*the discussion about how to reorganize the modules in Slicer should continue.
http://wiki.slicer.org/slicerWiki/index.php/Developer_Meetings/20130226#Module_reorganization

*installed extensions do not display their logos but a generic image. Why?
** Jc: See Issue [http://www.na-mic.org/Bug/view.php?id=1907 1907]
[[image:Screen Shot 2013-03-20 at 3.18.35 PM.png|200px|thumb|right|This generic logo is displayed for all installed extensions]]

*the majority of the extensions do not have "advertising" information available. Where does this information come from?
[[image:Screen Shot 2013-03-20 at 3.19.05 PM.png|200px|thumb|right|This is an example of the lack of advertising information that should be provided. virtually none of the extensions have that information available.]]

*The social media buttons do not work. What is their function?
** Jc: Waiting the functionality is implemented. Button will be hidden. See [https://github.com/midasplatform/slicerappstore/pull/38 slicerappstore/pull/38] [[image:Screen Shot 2013-03-20 at 3.28.33 PM.png|200px|thumb|right|These buttons do not do anything right now. If they were functional, what would they accomplish?]]
[[image:Bad-aspect-ratio-Screen Shot 2013-03-26 at 7.59.29 AM.png|200px|thumb|right|The squashed images look terrible. Also note that even the
social network icons are incorrectly resized so that google plus turns into google minus! Fail.]]

* Extension screenshots have the wrong aspect ratio
** appstore code should letterbox the images and not do a non-uniform scale

* The locale issue - who will take this on?
** http://www.na-mic.org/Bug/view.php?id=3029

* Release scheduling for 4.3, 4.4 ([http://www.na-mic.org/Bug/roadmap_page.php Roadmap])
** Remaining ITKv4 issues (broken CLIs, failing tests, win32 builds, others...?)
** Turning on SimpleITK

*Ohloh presence:
<pre>
From Jc:
There are currently three results for "Slicer4. See http://www.ohloh.net/p?q=slicer4
- Slicer4: http://www.ohloh.net/p/slicer
- pieper's Slicer4: http://www.ohloh.net/p/piepers_Slicer4
- Slicer: http://www.ohloh.net/p/3376
We should either have just "Slicer" / "3DSlicer"
or on project for each version:
3DSlicer 2
3DSlicer 3
3DSlicer 4
I would suggest the first approach.
Hth
Jc
</pre>
{{pre2|
From Julien:
I don't think ohloh is meant to host multiple versions of the same project, I would advise against having multiple versions on ohloh. Especially because Slicer3 is not active anymore and Slicer4 is built on top of Slicer3, it contains all the Slicer3 information.
If you look at the top 50 projects in ohloh, none of them are related to a specific version.
Julien.
}}

*Model Hierarchies plus scene views
** Crash on restoring Visual System scene view in Brain Atlas only after going into Models module [http://www.na-mic.org/Bug/view.php?id=2557 2557]

* CMake'ified python: https://github.com/jcfr/Slicer/tree/use-cmakeified-python
** Currently investigating:
*** Windows: Crash on start.
*** Linux: Failed to import some module.

== Conclusion ==
* Discussed module re-organization
** The idea would be to move every "legacy" cli into an extension and create a "meta" extension allowing to install all these cli modules at ones.
** Andriy is clarifying with Andras and Tamas the move of MRIBiasFieldCorrection" into legacy category.

* Ron asked where the extension description should be entered so that it appear on the extension catalog.
** Description of extension lives in the extension metadata specified in the CMakeLists.txt of the extension. For example: https://github.com/Slicer/SkullStripper/blob/master/CMakeLists.txt#L5-11
** Using the metadata from the CMakeLists, the extension description file is then generated and added to the ExtensionsIndex. See https://github.com/Slicer/ExtensionsIndex/blob/master/SkullStripper.s4ext#L37-38

*Ohloh presence: All agree we should have on entry named "Slicer".

* Nicole, Sankhesh and Julien discussed the "Model Hierarchies" + "scene views" issue

Documentation/Nightly/Developers/DevelopmentWithGit

2013-03-21T15:53:25Z

Sankhesh.jhaveri: /* Further Work */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

== Downloading Git ==
[http://www.paraview.org/Wiki/Git/Download| Download Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Testing this setup ==
* You can checkout my branch from [https://github.com/sankhesh/Slicer/tree/2834-consolidate-svn-git-hooks here].
* Once cloned, you can run the SetupForDevelopment script as described above to setup git hooks.
* Kindly review the changes, test the hooks and provide your valuable comments/suggestions.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]. A good description on this model is provided here: http://nvie.com/posts/a-successful-git-branching-model/
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-03-21T14:00:52Z

Sankhesh.jhaveri: /* pre-commit */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

== Downloading Git ==
[http://www.paraview.org/Wiki/Git/Download| Download Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not have very long lines (longer than 160 characters).

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Testing this setup ==
* You can checkout my branch from [https://github.com/sankhesh/Slicer/tree/2834-consolidate-svn-git-hooks here].
* Once cloned, you can run the SetupForDevelopment script as described above to setup git hooks.
* Kindly review the changes, test the hooks and provide your valuable comments/suggestions.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-03-20T20:02:16Z

Sankhesh.jhaveri: /* Git Hooks */

= Development with Git =
'''This page helps developers in the migration of Slicer4 from subversion to git.'''

== Downloading Git ==
[http://www.paraview.org/Wiki/Git/Download| Download Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==
* Hooks are stored in the main Slicer4 repository under a separate branch called [https://github.com/sankhesh/Slicer/tree/hooks hooks].
* These hooks are pulled when the SetupForDevelopment script is run. They are placed in the .git/hooks directory to install them.
* The following local hooks are currently installed. See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.

=== pre-commit ===
This runs during <code>git commit</code> before the commit message editor is fired up. It checks the identity and content of changes:

* Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
* Git's standard whitespace checks (see help on <code>git diff --check</code>)
* The staged changes do not introduce any leading TABs in source files (we indent with spaces)
* File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
* File size is not too large (don't commit big data files; prints limit and instructions on rejection)
* Files do not contain lines longer than 80 characters

One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers). NA-MIC/Slicer4 repository requires that all trailing whitespaces be removed before committing changes.
Text editors typically have a mode to highlight trailing whitespace:

{|
|-
|width=20%|Emacs
|
(custom-set-variables '(show-trailing-whitespace t))
|-
|width=20%|Vim
|
:highlight ExtraWhitespace ctermbg=red guibg=red
:match ExtraWhitespace /\s\+$/
|-
|width=20%|Visual Studio
|
To toggle viewing of white space characters, with a source
file document active, choose the menu item:

'''Edit > Advanced > View White Space'''

(2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
|-
|width=20%|Notepad++ (v5.6.7)
|
To eliminate trailing white space, choose the menu item:

'''Edit > Trim Trailing Space'''

To toggle viewing of white space characters, choose from the
menu items:

'''View > Show Symbol >''' (multiple items, choose one...)
|}

=== commit-msg ===

This runs during <code>git commit</code> after the commit message is saved. It checks the commit message format:

* The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line.
* The first line must not have leading or trailing whitespace.
* NA-MIC/Slicer4 requires commit messages to start with a commit type. Valid commit types are:
BUG: - a change made to fix a runtime issue
(crash, segmentation fault, exception, or incorrect result,
COMP: - a fix for a compilation issue, error or warning,
ENH: - new functionality added to the project,
PERF: - a performance improvement,
STYLE: - a change that does not impact the logic or execution of the code.
(improve coding style, comments, documentation).
Note that the ':'(colon) directly follows the commit tag. For example, it is: "STYLE:" not "STYLE :"
* The second line must be blank, if present.
* The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).

* GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.

** Examples of ''improper'' commit messages:

Fixed

This is too short and not informative at all. It does not name a commit type either.

ENH: I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.

This is too long and defeats the purpose of a Subject line.

** A good commit message would look something like this:

BUG: Fixed improper referencing of pointers

* Further adding the Mantis issue number to the commit message is good practice. This helps checking the history of the issue on Mantis and knowing why the change was done in the first place.

* Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.

== Testing this setup ==
* You can checkout my branch from [https://github.com/sankhesh/Slicer/tree/2834-consolidate-svn-git-hooks here].
* Once cloned, you can run the SetupForDevelopment script as described above to setup git hooks.
* Kindly review the changes, test the hooks and provide your valuable comments/suggestions.

== Further Work ==
* Setting up a master/next git development workflow similar to that followed by large open source projects such as [http://git.kernel.org/cgit/git/git.git/refs/?id=refs/heads/master git.git], [http://paraview.org/gitweb?p=ParaView.git;a=heads ParaView]
* Setting up Git aliases for better management of push/pull requests
* Possible gerrit integration

Documentation/Nightly/Developers/DevelopmentWithGit

2013-03-20T19:09:11Z

Sankhesh.jhaveri: /* Development with Git */

Documentation/Nightly/Developers/DevelopmentWithGit

2013-03-20T19:07:59Z

Sankhesh.jhaveri: Created page with '= Development with Git = '''This page is about the migration of Slicer4 from subversion to git.''' == Downloading Git == [http://www.paraview.org/Wiki/Git/Download| Download Ins…'

= Development with Git =
'''This page is about the migration of Slicer4 from subversion to git.'''

== Downloading Git ==
[http://www.paraview.org/Wiki/Git/Download| Download Instructions]

== Slicer Setup ==
{|
|-
|
1.
Follow instructions on [[Documentation/Nightly/Developers/StartHere|Start Here]] page to clone the Slicer repo from Github.
|
|-
|
2.
Run the developer setup script to set up your Slicer work tree
:<code>$ ./Utilities/SetupForDevelopment.sh</code>
|align="center"|
[https://github.com/sankhesh/Slicer/blob/2834-consolidate-svn-git-hooks/Utilities/SetupForDevelopment.sh <code>SetupForDevelopment.sh</code>]
|-
|
This script will setup git user info and git hooks.
|
|}

== Git Hooks ==

Documentation/Labs

2013-03-20T18:42:37Z

Sankhesh.jhaveri:

This is the place where we will keep track of our experiments.

== Internals ==
* [[{{FULLPAGENAME}}/DeprecatedModules|DeprecatedModules extension]]
* [[{{FULLPAGENAME}}/DevelopmentWithGit|Development with Git]]

== Libraries ==
* [[{{FULLPAGENAME}}/ITKv4|ITKv4]]
* [[{{FULLPAGENAME}}/Qt484|Qt484]]

== SlicerExecutionModel ==
* [[{{FULLPAGENAME}}/SlicerExecutionModel_Serialization|SlicerExecutionModel Serialization]]

== Python ==
* [[{{FULLPAGENAME}}/CMake-ified Python|CMake-ified Python]]
* [[{{FULLPAGENAME}}/CallingPythonMethodsFromCpp|Calling Python methods from Cpp]]
* [[{{FULLPAGENAME}}/IPython|IPython]]

== Compilers & IDE ==
* [[{{FULLPAGENAME}}/Ninja|Ninja]]
* [[{{FULLPAGENAME}}/VS2010|VS2010]]
* [[{{FULLPAGENAME}}/VS2012|VS2012]]

== Virtual Machines ==
* [[{{FULLPAGENAME}}/GPU Virtualization|GPU Virtualization]]

Documentation/Labs

2013-03-20T18:42:06Z

Sankhesh.jhaveri:

This is the place where we will keep track of our experiments.

== Internals ==
* [[{{FULLPAGENAME}}/DeprecatedModules|DeprecatedModules extension]]
* [[{{FULLPAGENAME}}/Git|Development with Git]]

== Libraries ==
* [[{{FULLPAGENAME}}/ITKv4|ITKv4]]
* [[{{FULLPAGENAME}}/Qt484|Qt484]]

== SlicerExecutionModel ==
* [[{{FULLPAGENAME}}/SlicerExecutionModel_Serialization|SlicerExecutionModel Serialization]]

== Python ==
* [[{{FULLPAGENAME}}/CMake-ified Python|CMake-ified Python]]
* [[{{FULLPAGENAME}}/CallingPythonMethodsFromCpp|Calling Python methods from Cpp]]
* [[{{FULLPAGENAME}}/IPython|IPython]]

== Compilers & IDE ==
* [[{{FULLPAGENAME}}/Ninja|Ninja]]
* [[{{FULLPAGENAME}}/VS2010|VS2010]]
* [[{{FULLPAGENAME}}/VS2012|VS2012]]

== Virtual Machines ==
* [[{{FULLPAGENAME}}/GPU Virtualization|GPU Virtualization]]

Developer Meetings/20130312

2013-03-12T17:24:42Z

Sankhesh.jhaveri: /* To discuss */

__TOC__

== To discuss ==
* Discuss Nrrd file loading issue on non american workstation. See http://slicer-devel.65872.n3.nabble.com/Re-Rounding-to-integer-tt4027985.html
* Demo of screenshot based testing See http://na-mic.org/Mantis/view.php?id=2567
** Topic pushed to : https://github.com/sankhesh/Slicer/tree/2567-screenshot-based-testing
** Improvements to ctkScreenshotDialog : https://github.com/sankhesh/CTK/tree/screeshot-resolution
** Baseline Images (data) :
*** http://slicer.kitware.com/midas3/folder/889
*** https://github.com/sankhesh/Slicer/tree/2567-screenshot-based-testing/Applications/SlicerApp/Data/Baseline
** CMake macro - slicer_add_qttesting_test (https://github.com/sankhesh/Slicer/blob/2567-screenshot-based-testing/CMake/SlicerMacroQtTesting.cmake)

== Conclusion ==

Developer Meetings/20130312

2013-03-12T17:22:19Z

Sankhesh.jhaveri: /* To discuss */

Documentation/Labs/Ninja

2013-02-04T18:28:04Z

Sankhesh.jhaveri: /* Test */

__TOC__

= Ninja =

Ninja is a small build system written with the goal of reducing build time of large projects like Slicer.

Ninja currently works well on linux and mac. It also works on windows, but that's very new and may have issues. It works as an alternative to more commonly known '''make''' or '''GNU Make (gmake)''' build systems.

For more details, head on to http://martine.github.com/ninja/

= Installation =

== Building from source ==
=== Linux / MacOSX ===

Open up a terminal and execute the following commands:

<pre>
git clone git://github.com/martine/ninja.git
cd ninja
./bootstrap.py
</pre>

NOTE: Make sure ''git'' is in the path.

=== Windows ===
Open up a Visual Studio command prompt and execute the following commands:

<pre>
git clone git://github.com/martine/ninja.git
cd ninja
.\bootstrap.py
</pre>

NOTE: Make sure ''git'' is in the path.

== Linux packages ==
There are packaged versions available for Ninja on various Linux flavors.

For example, installing the ninja package on Ubuntu can be done using:
<pre>sudo apt-get install ninja-build</pre>

= Using it =
*CMake has Ninja generator support beginning version 2.8.8

All one needs to do is choose ''Ninja'' as the generator for the project in ''cmake-gui'' (GUI for CMake)

OR

<pre>
cd Slicer/bld
ccmake ../src -GNinja
</pre>

*Once configured using CMake, simply run the <code>ninja</code> in the build directory.

*QtCreator has Ninja support beginning version 2.6

= Test =
I was able to use Ninja to build Slicer on Mac OSX and Linux Ubuntu.

All the dependencies of Slicer built fine and build time was reduced considerably.

The following table shows time statistics for a normal Slicer build on [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Developers/Factory Factory] machine on MacOSX.

{| border="1"
|-
! Build Type !! Command Used !! Time taken(seconds)
|-
| rowspan="2" align="center" | Fresh Build || align="center" | <code>make all -j9</code> || align="center" style="color:blue" | 1681
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:blue" | 1671
|-
| rowspan="2" align="center" | Re-Build without editing source || align="center" | <code>make all -j9</code> || align="center" style="color:red" | 102
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:green" | 2
|-
| rowspan="2" align="center" | Re-Build with minor edit || align="center" | <code>make all -j9</code> || align="center" style="color:red" | 1108
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:green" | 5
|-
|}

As observed, a fresh build takes approximately the same amount of time using both make and ninja. However, successive builds are much faster.

'''NOTE:''' Ninja uses all CPU cores by default but for comparison purposes I use the same number of cores for both the build systems.

I have tried using VS compiler on Windows for building Slicer using the above method. However, it was an unsuccessful attempt.
There were errors reported in building Python and ITK.

I will soon post my results of using QtCreator on Windows for building Slicer.

Documentation/Labs/Ninja

2013-02-04T18:27:33Z

Sankhesh.jhaveri: /* Test */

__TOC__

= Ninja =

Ninja is a small build system written with the goal of reducing build time of large projects like Slicer.

Ninja currently works well on linux and mac. It also works on windows, but that's very new and may have issues. It works as an alternative to more commonly known '''make''' or '''GNU Make (gmake)''' build systems.

For more details, head on to http://martine.github.com/ninja/

= Installation =

== Building from source ==
=== Linux / MacOSX ===

Open up a terminal and execute the following commands:

<pre>
git clone git://github.com/martine/ninja.git
cd ninja
./bootstrap.py
</pre>

NOTE: Make sure ''git'' is in the path.

=== Windows ===
Open up a Visual Studio command prompt and execute the following commands:

<pre>
git clone git://github.com/martine/ninja.git
cd ninja
.\bootstrap.py
</pre>

NOTE: Make sure ''git'' is in the path.

== Linux packages ==
There are packaged versions available for Ninja on various Linux flavors.

For example, installing the ninja package on Ubuntu can be done using:
<pre>sudo apt-get install ninja-build</pre>

= Using it =
*CMake has Ninja generator support beginning version 2.8.8

All one needs to do is choose ''Ninja'' as the generator for the project in ''cmake-gui'' (GUI for CMake)

OR

<pre>
cd Slicer/bld
ccmake ../src -GNinja
</pre>

*Once configured using CMake, simply run the <code>ninja</code> in the build directory.

*QtCreator has Ninja support beginning version 2.6

= Test =
I was able to use Ninja to build Slicer on Mac OSX and Linux Ubuntu.

All the dependencies of Slicer built fine and build time was reduced considerably.

The following table shows time statistics for a normal Slicer build on [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Developers/Factory Factory] machine on MacOSX.

{| border="1"
|-
! Build Type !! Command Used !! Time taken(seconds)
|-
| rowspan="2" align="center" | Fresh Build || align="center" | <code>make all -j9</code> || align="center" style="color:blue" | 1681
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:blue" | 1671
|-
| rowspan="2" align="center" | Re-Build without editing source || align="center" | <code>make all -j9</code> || align="center" style="color:red" | 102
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:green" | 2
|-
| rowspan="2" align="center" | Re-Build with minor edit || align="center" | <code>make all -j9</code> || align="center" style="color:red" | 1108
|-
| align="center" | <code>ninja -j9</code> || align="center" style="color:green" | 5
|-
|}

As observed, a fresh build takes approximately the same amount of time using both make and ninja. However, successive builds are much faster.

NOTE: Ninja uses all CPU cores by default but for comparison purposes I use the same number of cores for both the build systems.

I have tried using VS compiler on Windows for building Slicer using the above method. However, it was an unsuccessful attempt.
There were errors reported in building Python and ITK.

I will soon post my results of using QtCreator on Windows for building Slicer.

Documentation/Labs/Ninja

2013-02-03T21:11:28Z

Sankhesh.jhaveri: /* Using it */

Documentation/Labs/Ninja

2013-02-03T21:05:49Z

Sankhesh.jhaveri: /* Using it */

Documentation/Labs/Ninja

2013-02-03T20:54:30Z

Sankhesh.jhaveri: /* Linux packages */

Documentation/Labs/Ninja

2013-02-03T20:52:01Z

Sankhesh.jhaveri: Created page with '__TOC__ = Ninja = Ninja is a small build system written with the goal of reducing build time of large projects like Slicer. Ninja currently works well on linux and mac. It als…'

Developer Meetings/20130122

2013-01-18T16:20:03Z

Sankhesh.jhaveri: /* To discuss */

== To discuss ==
* Displayable Manager architecture with Laurent Chauvin - See http://slicer-devel.65872.n3.nabble.com/LightBoxManagerProxy-tp4027181p4027191.html
* Build issue on OpenSuse with Shireen Elhabian - See http://slicer-devel.65872.n3.nabble.com/Building-Slicer-on-OpenSUSE-tt4027139.html
* Transformation matrix pre-multiply vs post-multiply issue (ask Alex Yarmarkovich) - See http://na-mic.org/Mantis/view.php?id=2579

== Conclusion ==

Developer Meetings/20121030

2012-10-30T20:37:31Z

Sankhesh.jhaveri: /* Conclusion */

Attendees:

== To discuss ==

* Sync expectation regarding the CLI used to read DICOM

* Discuss how tutorials testing could be improved.

* Discuss [http://slicer.cdash.org/testDetails.php?test=3082872&build=45528 failing RSNA tutorial test.]

* Mailing List questions
** [http://slicer-devel.65872.n3.nabble.com/ijk-to-sliceoffset-on-a-slice-widget-tt4026548.html ijk to sliceoffset on a slice widget]
** [http://slicer-devel.65872.n3.nabble.com/Textured-models-tc4026535.html Texture Models]
** [http://slicer-users.65878.n3.nabble.com/loading-raw-data-on-Slicer4-td4025479.html Loading raw data in Slicer4]
** [http://slicer-users.65878.n3.nabble.com/Can-t-load-Dicom-data-td4025481.html Can't load DICOM data]
** [http://slicer-users.65878.n3.nabble.com/Installation-issues-td4025482.html Installation issue]
** [http://slicer-devel.65872.n3.nabble.com/Add-external-library-slicer-module-tt4026564.html Add external library to slicer module bundled within extension]

== Conclusion ==
* PETStandardUptakeValueComputation would need to be changed to accommodate new data. Two days before the release, it's not reasonable to change the module.
** Question: How the process could be improved to anticipate such issue early on ?
** Workaround: The data will be modified. Steve.
* Discuss failing test [http://slicer.cdash.org/testDetails.php?test=3082872&build=45528 py_RSNA2012Quant]
** Probably be related to the redesigned associated with ROI node
* Tutorial 6 - ABC extension
** Alex will talk with Marcel so that he recreate the tutorial for Slicer4
** Dataset also need to be updated to include updated atlas data
* Tutorial 0
** MacOSX - Last night build - OK [tested by Sonia]
* Tutorial 1
** No notes on the mantis issue. Jim will provide an update.
* Tutorial 2
** MacOSX - Last night build - OK [tested by Ron]
* Tutorial 3, 4, 5
** Works
*** Expect for VTK GPU RayCast method on old MacOSx
*** Method "OpenGL Texture raycaster" also have problem. See [http://na-mic.org/Mantis/view.php?id=2711 2711]
* Tutorial 7
** Csaba will be at RSNA
* Tutorial 8
** Ron will try
* Tutorial 9
** MacOSX - r21280 - OK
* Tutorial 10
* Tutorial 11
** See [http://www.na-mic.org/Bug/view.php?id=2513 2513]
** Mariana and Nicole are working on the data.
* Tutorial 12
** MacOSX - r21280 - OK
* Tutorial 13
** MacOSX - r21280 - segmentation volume color table is all black
** Linux - r21280 - segmentation volume color table is all black
*** Seems to be an issue specific to MRB files