Context Navigation

Nightly Build
Working with SVN
Testing Old Revisions
Repository Structure
Committing
Links

Development SVN

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

The SVN contains the development version of CKEditor. It does not 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 do not recommend using this version in a production environment. There are also security implications in doing so. To make the SVN version "production safe", it must be processed with CKReleaser (available inside the _dev folder). 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. Visit the following web site to download it:
http://nightly.ckeditor.com/

You may also directly test the nightly build online here.

The nightly build 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.

Working with SVN

Some basic SVN usage information can be found at the SVN Basics page.

Testing Old Revisions

There are occasions during the development, when bugs are introduced by recent changes in the code. In order to be able to determine when things changed, we have created a dedicated website with a list of all revisions done to the trunk:

http://rev.ckeditor.com/

The list on the above site is quite similar to the [log:CKEditor/trunk trunk log page], with the exception that it contains an additional column called "Test". A link can be found there to open the sample pages of CKEditor generated for each precise revision.

Repository Structure

CKEditor ------------+ 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 we will be working with everyday. Usually we will have local working copies of the trunk only (and possibly some branches).

Starting from version 2.4, the trunk will always have stable code which we can publish to the public SVN, and eventually release officially. As a result, 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 code chunk is ready, it can simply be merged into the trunk.

For code that does not bring instability, like trivial fixes or small features, there is no need to work in a separated branch. Such code can be committed directly to the trunk if you feel the code is OK and it is well tested. This approach makes the code 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 can decide to create a dedicated branch for it.
branches/versions: there could be branches for future versions, waiting while the previous ones are being tested and released.

Merging Branches

A common task during the 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 was 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 needed anymore, just delete it by using SVN delete.

If you are unsure about the process, do not be afraid of asking others to execute this task for you.

TortoiseSVN offers a nice tool to track the creation and 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 isolated thing. It makes code review and merge tasks easy.

The commit log message is very important. Do not 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:

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