This page is deprecated

The Apache VCL development community has moved to Git. We are still working out our Git workflow details. See the Working With Git Source Control page.

There is still some useful information on this page. The spirit of the points under Trunk Guidelines will not change, although the implementation details may. This page will be removed once this content has been migrated to a Git-focused page.

 

The Subversion repository is located at: https://svn.apache.org/repos/asf/vcl

The ASF's Infrastructure team maintains the Subversion repository.  More information can be found here.

Apache VCL Subversion Repository Layout

  • trunk
    • /trunk contains the latest code intended to be included in the next major (non-bugfix) release.
  • tags
    • The "tags" folder contains subfolders for every release candidate and release.
    • After a version if released, the corresponding folder under "tags" shall never be changed again.
    • The "tags" folder is useful when you are troubleshooting a problem occurring for a particular release.
    branches
    • Used to maintain branches of code based on the previous major release which only contain bug and security fixes.
    • Code under /bugfix SHALL NOT contain ANY code containing new features not included in the previous release.
  • reports
    • The /reports folder is not maintained.  It used to be intended to include all reports sent to the ASF incubator and board.
  • sandbox
    • /sandbox is intended for committers to be able to share code which is not currently intended to be released with Apache VCL proper.
    • /sandbox may be used for experimental features a committer wants to share but does not intend to support.
  • site
    • /site folder contains the vcl.apache.org website code.
    • /site is not related in any way to the website included in the Apache VCL codebase.

Trunk Guidelines

  • All developers should check out trunk and develop against it.
  • All developers should routinely perform a Subversion update (svn up) for their checked out copy in order to receive code changes other committers have made to /trunk
  • Committers commit their day-to-day changes to /trunk.
  • Committers commit code contributions from non-committer developers to /trunk once reviewed.
  • Changes committed to trunk should be fairly small
    • Small commits make it easier for other developers to review the changes.
    • Large commits to trunk are highly discouraged unless there is a valid reason for it which was previously discussed on the dev list.
    • Do NOT develop a large new feature or make a major change to a large section of code and commit it all at once.  Instead, commit smaller changes as you make progress.
  • All commits to trunk should contain a Subversion comment linked to a JIRA issue unless the commit is very trivial such as fixing a typo or commenting out a logfile debugging line.
  • All Subversion comments should be detailed enough to allow other developers to fully grasp the change and rationale for it.
    • Do NOT simply say "blah wasn't working correctly".  Describe exactly what was changed to make "blah" work correctly.
    • Do NOT simply say "added foo" or "removed bar".  Describe why the change was made.

Online Repository Viewing

https://svn.apache.org/viewvc/vcl

  • No labels