Repository URL
https://repos.exphosted.com/svnrepos/crossbow/trunk
To start svn server (only for admins): svnserve -d --listen-port 3690 --listen-host dev01.exphosted.com -r /svnroot/crossbow
Repository Structure Main Source
/
crossbow/
trunk/
tags/
branches/
Repository Structure Collaboration (BBB)
https://repos.exphosted.com/svnrepos/collaboration/bbb/trunk/
/
collaboration/
bbb/
trunk/
tags/
branches/
Repository Structure Meeting
https://repos.exphosted.com/svnrepos/meeting/client/trunk/
/
meeting/
client/
trunk/
tags/
branches/
https://repos.exphosted.com/svnrepos/meeting/server/trunk/
/
meeting/
server/
trunk/
tags/
branches/
Repository Structure Talent
https://repos.exphosted.com/svnrepos/talent/trunk/
/
talent/
trunk/
tags/
branches/
Repository Commands
Checkout: svn co --username=<your username> https://repos.exphosted.com/svnrepos/crossbow/trunk Update: svn up --username=<your username>
Process
Permanent development takes place on the main branch “trunk”. At the time of version release “trunk” is tagged and a “release” branch is created on the base of this tag. Bug's are fixed in the “release” branch and this is the branch that will be deployed. Once released, changes from the “release” branch are merged with the “trunk”. All weekly internal releases will be tagged(and not branched) and deployed. There will be no changes checked into a tag.
To handle long running changes or long isolated work, a private branch should be created and all changes performed there. Once changes have been made and tested, this should be carefully merged back into the “trunk”.
When a change is committed to the repository, care should be taken to make sure that the change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. The checkin comment should be descriptive and explain very clearly what was committed. At a minimum, the following should be reflected in the checkin comments:
Issue#: NNNNNNN Reviewer: Name Browser Tested: Firefox/IE Tests Written: Y/N United Tested: Y/N Description:
Also, as many two-way links, between the SVN revision number and the issue in the issue-tracking database, should be created:
- refer to a specific issue ID in every commit log message
- before closing an issue, name the revision number(s) responsible for the change
Here are some basic things to keep in mind:
- Users commit their day-to-day work on /trunk
- /trunk must compile and pass regression tests at all times. Developers who violate this rule will be humiliated! See the build status here: http://tracker.exphosted.com/
- a single commit (changeset) must not be so large so as to discourage peer-review
- if #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk
