Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=PLATFORM_STANDARDS_REPOSITORY_R1, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

Correct and expand PLATFORM_STANDARDS_REPOSITORY

Task requirements

• Remove numbering as it is inconsistent
• Link this page in PLATFORM_STANDARDS_GENERAL
• Add "Naming convention" for the files in the repository
  • for sources
  • for schedule, reports, etc.
• Add related things from SCS_REPO_MAINTENANCE_R1
• Add links to svn clients
• Decide if it is convenient to add link to platform structure
• Maintenance and backup information
• Refactor the structure of the document in Design section (and apply it in implementation).

Task result

PLATFORM_STANDARDS_REPOSITORY

Implementation idea

For Maintenance and backup information research which pages contain relevant information and link them

Related

SCS_REPO_MAINTENANCE_R0
SCS_REPO_MAINTENANCE_R1
SCS_REPO_MIGRATE_R0
SCS_REPO_MIGRATE_R1
REPO_MAINTENANCE

How to demo

Show PLATFORM_STANDARDS_REPOSITORY

Design

• Created structure with paragraphs and bullets instead of numbering
• Created paragraph about naming conventions

  === 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 [wiki:PLATFORM_STRUCTURE].
   * Tags - each tag is stored in /tags/m??-??? directory, where m??-??? stands for the milestone and its name for example m02-pre2.
  

• Added information from REPO_MAINTENANCE

  === 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.[[BR]]
  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 [http://tortoisesvn.net/downloads 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://asteasolutions.net/sophie2-repo/trunk (or svn://asteasolutions.net/sophie-jr/trunk) use svn://asteasolutions.net/sophie2-repo/tags/m??-??? (or svn://asteasolutions.net/sophie-jr/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 [http://tortoisesvn.net/downloads here].
  

• Added link to TortoiseSVN download section.
• Improved committing rules

  === 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.
  

• REPO_MAINTENANCE is now obsolete and will be removed in the implementation phase.
• Link in PLATFORM_STANDARDS_GENERAL will be added in implementation phase.

Implementation

• The changes of the some paragraphs described in design phase were applied.
• Some new paragraphs created in the design phase were added
• Some corrections to other paragraphs were made (changing addresses for the new repository and etc.)
• Applied new structure to the document, now it is divided on chapters and every chapter contains bullets.
• The result is improved structure and added content to PLATFORM_STANDARDS_REPOSITORY

Testing

Comments

^{(Write comments for this or later revisions here.)}