wiki:SVN

Context Navigation

Version 18 (modified by Frederico Caldeira Knabben, 18 years ago) (diff)
The trunk version runs using the _source files, so there is no need to "build" it

Development SVN

The SVN repository used for the development can be found at (browsable):
http://svn.fckeditor.net

The SVN contains the "development version" of FCKeditor. It doesn't reflect the contents of public distributions. Actually, some files are not present in the public downloads (like the "_dev" folder or the compressed "js" files, for example).

We don't recommend using this version on production. There are also security implications on doing so. To make the SVN version "production safe", it must be processed with FCKreleaser (available inside _dev). A safer and easier option is to simply use the Nightly Build, which is already processed.

Nightly Build

Every night, at 0:30 PST, a "Nightly Build" is generated, from the SVN version. You may download it from one of the following links:

You may also test it online here.

The nightly is processed for public distribution. As the fixes and features available on nightlies are still under testing and development, it may be used on production systems at your own risk.

Repository Structure

FCKeditor -----------+ Every subproject will have a directory in the root.
    trunk -----------+ This is the development place.
    branches
        developers --+
        features     | Isolated development spaces.
        versions ----+
    tags
        2.3.2 -------+
        2.3.1        | A tag will be available for each version release. 
        2.3          | It contains the development version (trunk) at release time.
        1.6.1 -------+

All subprojects in the repository will present a structure similar to the above.

The "trunk"

The trunk is the effective place were will be working everyday. Usually we'll have local working copies of the trunk only (and possibly any branch).

Starting from version 2.4, the trunk will always have stable code which we can publish to the public SVN, and eventually release officially. So, only important bugs and small changes will be committed here, while more delicate and extensive developments will be done in a "branch".

Branches

Branches give us isolated environments for development, and once tested and confirmed a new work is ready, it can be simply merged in the trunk.

For code that doesn't bring instability, like trivial fixes or small features, there is no need to work on a separated branch. It can be committed directly to the trunk if you feel the code is ok and it is well tested. It makes the management easier.

The branches could be created in the following spaces:

branches/developers: each developer may have a private branch under this directory. The directory name is the developer name (fredck, for example). The developer himself can decide to use it or not, and have complete freedom for it.
branches/features: if a feature is too big and complex, a developer could decide to create a dedicated branch for it.
branches/versions: there could be branches for future versions, waiting while previous ones are being tested and released.

Merging Branches

A common task during a branch development, is to merge changes made in the trunk to the branch, leaving it always up to date with the trunk. Remember that merges must be done from the last revision merged, starting from the revision from which the branch has been created.

When merging branches to the trunk, first merge the trunk to the branch and check that everything is ok. Make the necessary changes and commit the branch. Then switch to the trunk and merge the differences between the branch HEAD and the last trunk revision you have just merged to the branch (usually HEAD). Then, if the branch is not anymore needed, just delete it (SVN delete I mean).

If you are insecure, don't be afraid of asking others to execute this task for you.

TortoiseSVN offers a nice tool to track the creation an life-cicle of branches. It is called "Revision graph". The SVN log can also be used for it.

Committing

Try to make a single commit for each fix or feature. Avoid making big commits with lots of changes. This separation makes each commit an isolate thing. It makes code review and merge tasks easy.

The commit log message is very important. Don't underestimate it. It must be well written and informative. Whenever possible, make references to related trac items, like tickets or changesets. You may use one of the "standard" messages, like the following examples:

Fixed #81: IE has a DOM bug that caused FCKDomTools.RTrimNode to break.
Merged trunk r131:132 into branches/versions/2.4.x
FCKeditor 2.4 tagging

Context Navigation

Table of Contents