Repository

  • You can download the repository from the external link:  svn://sophie2.org/sophie2 or the internal one:  svn://10.10.117.3/sophie2. That is where the main line of development will be.
  • The current sources for the Sophie-JR project are located in the trunk/ folder;
  • The branches and tags are located in the branches/, tags/ folders;
  • Reports and schedule documents can be found in the manage/ folder;

Deploying A Project In A Repository

  • Checkout the project repository
    • In Windows:
      • Right-click in a new empty folder and choose "Create repository here" option from the TortoiseSVN submenu.
      • Choose "SVN Checkout...". Enter the URL of the repository of the Sophie2 project. The URL is  svn://sophie2.org/sophie2.
      • Choose your checkout directory (sophie2-repo). It is set by default to be the empty folder in which you choose "SVN Checkout...".
      • After you have created the repository open the folder. There you must see the following directories: branches, tags, trunk.
      • However you must add the manage directory, to do so:
        • Right click in your repository folder (folder containing branches, tags, trunk)
        • From TortoiseSVN menu choose Repo-browser
        • Window with all repository contents will appear (including manage directory)
        • Select all directories in the righthand part of the window and right click
        • Choose Checkout and in the opened browser window select your repository folder
        • Confirm with OK and use your username and password where needed
      • Now you have fully functional repository.
    • In Mac/Linux:

Build the project in Eclipse by following the instructions on the Eclipse Integration page.

Committing Rules

  • SVN commits should have clear message. You should write in your comment the name and id of the task for which is the commit. Example: #112 (PLUGIN_SUPPORT_LIB_BASE_R0) - implemented. The other modules need to be updated according to it.
  • Committing without a comment is absolutely impermissible (that is valid even when committing only a daily report).
  • Always write a comment which task(s) affects your commit (in other words which task you are working on). If it is hard to state what the change is, then probably you are not working on one thing.
  • When you commit code be sure that it is written following the code standards. Do not commit bad code - generally, you should not commit before a review is passed.

Reverting

If some bad code is committed (for example one that breaks changes) there may be a need to revert it. Reverting is done by:

  • creating an inverting diff (between revisions, or several revision numbers)
  • applying that diff to the current source code.
  • commiting
  • Useful stuff
    • Reverting To a Previous Revision. You can revert files or folders or the entire project to a previous revision of the repository using merging:

Example:

svn merge -r BASE:15 

svn will revert the working copy of the project to revision 15. The changes will only take place on the working copy and will not be committed to the repository until you tell it to do so:

svn commit -m 'Reverting repository to r15.'

Repository Usage Rights

  • unregistered users
    • unregistered users are able to download all directories in the repository except the manage folder
  • registered users
    • registered users are able to download all content of the repository including the manage folder that contains weekly and iteration reports and some more internal information
    • registered users have the right to commit in the repository following the commit rules

Naming Conventions

  • Daily reports
    • the daily reports are stored in /manage/reports/m??/devid-YYYY-MM-DD.txt
      • m?? is the name of current milestone, for example m03.
      • devid stands for developer's id that is used in trac and svn, for example peko.
      • YYYY-MM-DD is the date in iso format (year, month, day), for example 2009-01-08.
      • do not forget to add .txt extension if you work on Linux, example for correct daily report name is peko-2009-01-08.txt that is stored in /manage/reports/m03 directory.
  • Monthly reports
    • the monthly reports are stored in /manage/reports/m??/devid-m??-final.txt
      • m?? is the name of current milestone, for example m03.
      • devid stands for developer's id that is used by in trac and svn, for example peko.
      • do not forget to add .txt extension if you work on Linux, example for correct monthly report name is peko-m03-final.txt that is stored in /manage/reports/m03 directory.
  • Source code - see PLATFORM_STRUCTURE.
  • Tags - each tag is stored in /tags/m??-??? directory, where m??-??? stands for the milestone and its name for example m02-pre2.

Creating Tag

Another common version control concept is a tag. A tag is just a “snapshot” of a project in time. In Subversion, this idea already seems to be everywhere. Each repository revision is exactly that—a snapshot of the filesystem after each commit.

However, people often want to give more human-friendly names to tags, like release-1.0. And they want to make snapshots of smaller subdirectories of the filesystem. After all, it's not so easy to remember that release-1.0 of a piece of software is a particular subdirectory of revision 4822.

  • How to create a tag on Linux
    $ svn copy svn://sophie2.org/sophie2/trunk \
               svn://sophie2.org/sophie2/tags/m??-??? \
          -m "Comment."
    Committed revision 351.
    

Here m??-??? stands for the milestone and its name for example m01-pre1.
After the copy completes, the new m??-??? directory is forever a snapshot of how the project looked in the HEAD revision at the time you made the copy. Of course you might want to be more precise about exactly which revision you copy, in case somebody else may have committed changes to the project when you weren't looking. So if you know that revision 350 of /sophie2-repo/trunk is exactly the snapshot you want, you can specify it by passing -r 350 to the svn copy command. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch.

  • How to create a tag on Windows with  TortoiseSVN:
    • Update first.
    • Go to "trunk" folder in your local repository
    • Right click on it
    • TortoiseSVN -> Branch/tag
    • Dialog window appears. Now instead of  svn://sophie2.org/sophie2/trunk use  svn://sophie2.org/sophie2/tags/m??-???. Here m??-??? stands for the milestone and its name for example m01-pre1.
    • It is obligatory to write a comment when you commit.
    • Tags must be created at the end of each iteration when the work is frozen.
    • You can download TortoiseSVN from  here.

Comments

  • Since most of the release team is remote, it is hardly possible to have your task reviewed without a commit. --boyan@2009-01-12
  • Not explained how the registered users can download the "manage" directory. For example, with tortoiseSVN you have to use the repo-browser, since it does not ask you for username/password. --kyli
  • I think that it should be noted that one should not branch/tag the whole repo. --pap@2009-01-15
  • I think that the "Deploying a project in a Repository" section is not correctly named and the first bullet should be deleted. I think it was broken in some of the previous docs rearangements as deploying into repository and checking out of it are two different things. --pap@2009-01-15
  • You should add a section describing how to checkout the manage folder under Linux. I did this via Eclipse but I don't think it is the best way. I did so because my svn client refused to use the creditentials I gave it. --pap@2009-01-15
  • There is no such thing as the Sophie-JR project anymore or at least they don't have place in this document. --pap@2009-01-15
  • Probably internal information as manage directory should not be noted here - it is internal information, not needed by the community. This can be placed somewhere else, not exactly sure where --deyan@2009-02-03