Difference between revisions of "Dev:Source code"

From Synfig Studio :: Documentation
Jump to: navigation, search
(Add sourceforge git access and reformat the page layout)
m
 
(16 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[Category:Code]] [[Category:Permalink]]
+
{{Title|Source code}}
 +
{{Category|Code}}
 +
{{Category|Permalink}}
 +
 
 +
Hey you! Do you want access to bleeding-edge Synfig? Well, I have good news. We provide a way to get the code:  
  
Hey you! Do you want access to bleeding-edge Synfig? Well, I have good news. We provide two ways to get the code:
 
*Using subversion (three repositories)
 
 
*Using git (one repository)
 
*Using git (one repository)
  
Once you grab the code, you will need to bootstrap the build environment and then [[Build instructions|build the code]].
+
Once you grab the code, you will need to follow the {{l|Dev:Build Instructions|build instructions}}.
  
Commit notifications are sent to [http://cia.vc/stats/project/synfig CIA] and show up in the [[Contact|IRC channel]].
+
Commit notifications to master branch are <strike>sent to [http://cia.vc/stats/project/synfig CIA] and</strike> shown up in the {{l|Contact|IRC channel}}.
  
While you are browsing the code, you may wish to refer to these links:
+
== GIT repository at Github==
 
+
* [http://sourceforge.net/tracker/?atid=757416&group_id=144022&func=browse Bug tracker]
+
* [http://patches.synfig.org/groups/synfig/ Patches review board]
+
* [http://synfig.org/api/ API documentation]
+
* [[Source Outline|source code outline]]
+
* [[Source Glossary|source code glossary]]
+
* [[Source:ETL_make_check|ETL make check failures]]
+
* [[Source:Layers|Mapping between layer types, classes and .cpp files]]
+
* [[Source:class_ValueNode|ValueNode types]]
+
* [[Source:BlendMethods|Blend Method enumeration values]]
+
 
+
 
+
== SVN repository at Sourceforge ==
+
  
 
Anonymous access:  
 
Anonymous access:  
* https://synfig.svn.sourceforge.net/svnroot/synfig/ETL/
 
* https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-core/
 
* https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-studio/
 
  
Web interface:
+
  git clone git://github.com/synfig/synfig.git
* http://synfig.svn.sourceforge.net/viewvc/synfig/
+
People with commit access should use this command instead:
  
To checkout code from the command line:
+
  git clone git@github.com:synfig/synfig.git
  
  svn co https://synfig.svn.sourceforge.net/svnroot/synfig/ETL/trunk/ etl
+
Or this one if you prefer https protocol:
  svn co https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-core/trunk/ synfig-core
+
  svn co https://synfig.svn.sourceforge.net/svnroot/synfig/synfig-studio/trunk/ synfig-studio
+
  
You can also download a [http://synfig.org/code/synfig-svn-checkout.tar.gz daily updated svn checkout] that you can update using svn up. This was created using a [[Subversion|procedure]] by [[User:Dooglus|dooglus]].
+
git clone https://github.com/synfig/synfig.git
  
You can also download daily updated svn exports for [http://synfig.org/code/ETL-svn.tar.gz ETL], [http://synfig.org/code/synfig-svn.tar.gz synfig], [http://synfig.org/code/synfigstudio-svn.tar.gz synfigstudio].
+
You can also check out the [https://github.com/synfig/synfig web interface] to that repository.
  
 +
Check out [https://help.github.com Github help page] for further references.
  
== GIT repository at Sorceforge==
+
=Proposed git workflow=
  
[[User:Genete|Genete]] is maintaining a single git repository at Sourceforge. It includes the changes done in SVN and also other code development his working on. The idea is completely migrate to git in the future.
+
* Consider the '''master''' branch the stable one.  
 +
* Each coder should have a '''username_master''' branch where all the small changes are done.
 +
* Once the '''username_master''' branch is considered stable it can be rebased/merged to '''master'''.
 +
* Work on new non-trivial features/fixes on '''username_feature''' branches.
 +
* Once the '''username_feature''' branch is considered stable it can be rebased/merged to '''master'''.
 +
* Obviously commit trivial fixes straight to the '''master'''.
 +
* If it is possible, rebase & rework branches to keep history more sane, linear and atomic.
 +
* Releases are tagged according to following criteria:
 +
** If the release consist on a few trivial set of features or bug fixes then increase the third numeration level: 0.64.0 -> 0.64.1
 +
** If the release consist on a set of important features and/or includes non backward compatible file format, then increase the second level numeration: 0.64.1 -> 0.65.0
  
Anonymous access:
+
=See Also=
 
+
While you are browsing the code, you may wish to refer to these links:
  git clone git://synfig.git.sourceforge.net/gitroot/synfig
+
+
People with commit access should use this command instead:
+
 
+
  git clone ssh://USERNAME@synfig.git.sourceforge.net/gitroot/synfig
+
 
+
You can also check out the [http://synfig.git.sourceforge.net/git/gitweb.cgi?p=synfig web interface] to that repository.
+
 
+
Check out [http://sourceforge.net/apps/trac/sourceforge/wiki/Git Sourceforge Git wiki page] for further references.
+
 
+
==Proposed workflow and other repositories ==
+
 
+
Proposed git workflow:
+
  
* Do all work on the '''master''' branch
+
* [http://www.synfig.org/issues/thebuggenie/synfig Bug tracker]
* Latest stable releases should be tagged with '''stable-release'''.
+
* [http://sourceforge.net/p/synfig/mailman/synfig-devl/ Synfig Dev mailing list]
* Latest development releases should be tagged with '''devel-release'''.
+
==Code overview==
* All releases should be tagged with their version number (with no extra chars): '''0.61.08'''.
+
* [http://download.tuxfamily.org/synfig/api/index.html API documentation]
* For now, we don't need a stable release branch, when/if we do:
+
* {{l|Dev:Source Outline|source code outline}}
** Branch the '''stable-release''' tag (or whatever is appropriate) to something like '''0.62'''.
+
* {{l|Dev:Source Glossary|source code glossary}}
** Cherry-pick commits from the '''master''' branch to the stable branch where possible.
+
* {{l|Dev:Layers|Mapping between layer types, classes and .cpp files}}
** Commit directly to the stable branch only when cherry-picks are not possible.
+
* {{l|Dev:class_ValueNode|ValueNode types}}
* Work on new non-trivial features/fixes on public topic branches where possible
+
* {{l|Dev:BlendMethods|Blend Method enumeration values}}
* Obviously commit trivial fixes straight to the '''master''' or the stable branch.
+
==Others==
* Rebase & rework branches to keep history more sane, linear and atomic
+
* {{l|Dev:ETL_make_check|ETL make check failures}}
 +
* {{l|Interesting Readings}}
  
Proposed set of git repositories:
+
<!--
 +
Proposed set of git repositories (this section is outdated):
  
 
* admin.git - gitosis admin settings - holds groups, repos and users
 
* admin.git - gitosis admin settings - holds groups, repos and users
Line 92: Line 75:
 
* misc/* - various stuff needed
 
* misc/* - various stuff needed
 
** misc/svn2git.git - the scripts used to convert the SVN repo to git
 
** misc/svn2git.git - the scripts used to convert the SVN repo to git
 +
-->

Latest revision as of 17:55, 16 March 2017

Hey you! Do you want access to bleeding-edge Synfig? Well, I have good news. We provide a way to get the code:

  • Using git (one repository)

Once you grab the code, you will need to follow the build instructions.

Commit notifications to master branch are sent to CIA and shown up in the IRC channel.

GIT repository at Github

Anonymous access:

 git clone git://github.com/synfig/synfig.git 

People with commit access should use this command instead:

 git clone git@github.com:synfig/synfig.git

Or this one if you prefer https protocol:

git clone https://github.com/synfig/synfig.git

You can also check out the web interface to that repository.

Check out Github help page for further references.

Proposed git workflow

  • Consider the master branch the stable one.
  • Each coder should have a username_master branch where all the small changes are done.
  • Once the username_master branch is considered stable it can be rebased/merged to master.
  • Work on new non-trivial features/fixes on username_feature branches.
  • Once the username_feature branch is considered stable it can be rebased/merged to master.
  • Obviously commit trivial fixes straight to the master.
  • If it is possible, rebase & rework branches to keep history more sane, linear and atomic.
  • Releases are tagged according to following criteria:
    • If the release consist on a few trivial set of features or bug fixes then increase the third numeration level: 0.64.0 -> 0.64.1
    • If the release consist on a set of important features and/or includes non backward compatible file format, then increase the second level numeration: 0.64.1 -> 0.65.0

See Also

While you are browsing the code, you may wish to refer to these links:

Code overview

Others