Dev:Source code

From Synfig Studio :: Documentation
Revision as of 08:56, 8 September 2009 by Zelgadis (Talk | contribs) (Text replace - '[[' to '{{l|')

Jump to: navigation, search

{{l|Category:Code]] {{l|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:

  • Using git (one repository)
  • Using svn (three repositories). DISCONTINUED

Once you grab the code, you will need to follow the {{l|Build instructions|build instructions]].

Commit notifications to master branch are sent to CIA and show up in the {{l|Contact|IRC channel]].

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

  • Bug tracker
  • Patches review board
  • API documentation
  • {{l|Source Outline|source code outline]]
  • {{l|Source Glossary|source code glossary]]
  • {{l|Source:ETL_make_check|ETL make check failures]]
  • {{l|Source:Layers|Mapping between layer types, classes and .cpp files]]
  • {{l|Source:class_ValueNode|ValueNode types]]
  • {{l|Source:BlendMethods|Blend Method enumeration values]]
  • {{l|Interesting Readings]]

GIT repository at Sorceforge

Anonymous access:

 git clone git:// 

People with commit access should use this command instead:

 git clone ssh://

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

Check out Sourceforge Git wiki page for further references.


Anonymous access:

Web interface:

To checkout code from the command line:

 svn co etl
 svn co synfig-core
 svn co synfig-studio

You can also download a daily updated svn checkout that you can update using svn up. This was created using a {{l|Subversion|procedure]] by {{l|User:Dooglus|dooglus]].

You can also download daily updated svn exports for ETL, synfig, synfigstudio.

Proposed workflow and other repositories

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.61.09 -> 0.61.10
    • 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.61.09 -> 0.62.00

Proposed set of git repositories:

  • admin.git - gitosis admin settings - holds groups, repos and users
  • code/* - direct conversions from SVN
    • code/ETL.git - ETL
    • code/synfig.git - synfig
    • code/synfigstudio.git - synfigstudio
  • pkg/* - bits for various packaging systems
    • pkg/windows.git - Windows packaging (needs separating from the code repos)
    • pkg/macos.git - MacOS packaging (needs separating from the code repos)
    • pkg/jhbuild.git - JHBuild moduleset (needs writing)
    • pkg/autopackage.git - Autopackage bits (needs writing)
  • web/* - various bits used to maintain the website
    • web/skin.git - skin for the website
    • web/content.git - content for the website (pending switch to ikiwiki)
  • misc/* - various stuff needed
    • misc/svn2git.git - the scripts used to convert the SVN repo to git