Dev:Source code

From Synfig Studio :: Documentation
Revision as of 17:48, 19 June 2009 by Rore (Talk | contribs) (added a link to the Interesting_links page.)

Jump to: navigation, search

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)

Once you grab the code, you will need to bootstrap the build environment and then build the code.

Commit notifications are sent to CIA and show up in the IRC channel.

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

SVN repository at Sourceforge

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 procedure by dooglus.

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

GIT repository at Sorceforge

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.

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.

Proposed workflow and other repositories

Proposed git workflow:

  • Do all work on the master branch
  • Latest stable releases should be tagged with stable-release.
  • Latest development releases should be tagged with devel-release.
  • All releases should be tagged with their version number (with no extra chars): 0.61.08.
  • For now, we don't need a stable release branch, when/if we do:
    • Branch the stable-release tag (or whatever is appropriate) to something like 0.62.
    • Cherry-pick commits from the master branch to the stable branch where possible.
    • Commit directly to the stable branch only when cherry-picks are not possible.
  • Work on new non-trivial features/fixes on public topic branches where possible
  • Obviously commit trivial fixes straight to the master or the stable branch.
  • Rebase & rework branches to keep history more sane, linear and atomic

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