DSDP/TML/SVN Migration Plan

TmL SVN Migration Plan

The TmL repository is currently under CVS servers and it was decided migrate this repository to use a Subversion server. This migration it a good opportunity to define a set of rules of branch creation, tag name conventions and folder structure that will be used by the project in the new server.

Contribution with this policy

Your contributon is very important to make this document a complete reference of SVN policy for TmL. Please join to us discussing it in the mailing list dsdp-tml-dev@eclipse.org.

Deliverables

The discussion for this event opens: Aug 22th, 2008 and it is schedule to finish in Aug 29th , 2008. After that we will summaryze the mailing list comments, generate a pdf final version and attach to the Bugzilla entry to start the process of migration. The backup strategies and dates for this migration will be announce when it is available.

Subversion Folder Structure

trunk\ 

Main line development. Most daily work happens here.

tags\ 

Frozen release milestones. Copies of trunk at the time of specific milestones, such as review, beta, final. Makes it easy to see the files used in a given release. When you create a new folder under tags, it's said that trunk has been "tagged." Never modify files in tags folders; they're for historical reference only.

branches\ 

Separate development branches. Copies of trunk for development work that needs to be done independently of the main line. For example, an experiment to implement many global changes or other major changes that would interfere with current work in trunk. A branch could also be created to begin work on the next release before the current release in trunk is finished. Then when the current release is finished (and trunk is "tagged"), you can merge changes in the branch back into trunk.

Subversion Folder Structure

• org.eclipse.tml/ - Root of Eclipse TmL repository
  • trunk/ - Main line of development. Primary work is here
  • tags/ - Copies of trunk, tagged for each release
  • branches/ - Experimental development branch copies of trunk
  • users/ - Contains a folder for each user.A sandbox to experiment with SVN, temp location

• org.eclipse.tml/trunk/ - TmL main line of development
  • <component>/ - Component of TmL
  • core/ - Core component
  • common/ - Common APIs , logging, internationalization, image registry, exception handling
  • device/ - Device framework
  • proxy/ - Device Proxy
  • proc/ - Proc Filesystem
  • vnc/ - VNC Viewer
  • protocol/ - Protocol mechanism

• org.eclipse.tml/trunk/<component>/ - TmL <component> folder
  • plugins/ - Plugins
  • features/ - Features
  • builds/ - Build scripts , update site
  • examples/ - Examples plugins and projects
  • tests/ - JUnit plugins and test files
  • docs/ - Documentation
    • javadoc/ - Javadoc
    • help/ - Help plugins
    • process/ - Process documents and templates: architecture, design, whitepapers
    • others/ - Tutorial, presentation, how-to

org.eclipse.tml/tags/ Copies of trunk, tagged for each release releases/ Tags for complete releases components/ Tags for specific components

org.eclipse.tml/branches/ Experimental development branch copies of trunk releases/ Branches for complete releases components/ Branches for specific components development/ Branches for development

Tags and Branches Name Convention

• component

^Name of the component for which this tag folder contains the source files. For example, common, proc. protocol, vnc, proxy, core. ^

version The deliverable or product version. For help systems, use the product's version number. For deliverables that don't ship with something that has a version number, use the format 001, 002, 003, etc. Tags versions are three number format: 0.1.0 , branch versios are two number format: 0.1

milestone The milestone number (just for sorting purposes) followed by the milestone name. For example, 01-review, 02-beta, 03-review, 04-final.

tags/releases/ tml_<version>_<milestone> tml_0.1.0_final tml_0.1.0_beta tml_0.1.0

tags/components/ tml_component_version_milestone tml_vnc_0.1.0_final tml_vnc_0.1.1_final

branches/develop/ tml_bug_XXXXXX tml_bug_XXXXXX_YYYYYY

branches/develop/releases/ tml_0.1_test tml_0.1_wfr004 tml_0.1_bug_XXXXXX

branches/components/ tml_vnc_0.1_beta tml_vnc_0.2_final

TmL SVN Version Policy

• One bug can be addressed by only one branch • One branch can addresses N bugs • Branches that addresses more than one bug should be named (tml_bugs_XXXXXX_YYYYYY) • If the bugs are too small, we can group more than one in the same branch and put the name of the most expressive bug. • The developer should commit the code every day to make sure that the code will be safe in the official repository. The developed branch could be broke but the trunk might be always running as well. • Nightly builds commonly will run over trunk, so when bugs are merged to trunk the developer must be sure that the merge does not break the build. • A bug is fixed when it is merged. • For bugs which the target milestone is not the current stream (for instance we are working in 0.1 and the bug fixed is for 0.2), this bug will keep opened until the merge could be available.

TmL Bugs Rules

• Versions are in the format x.y.z o X – changes if there are API changes o Y – changes if there are new features and major bug fixes o Z – changes if there are only bug fixes and minor bug fixes

• Changing the Z versions.

Bug logged in version Bug fixes Enhancement x.y.z All to z+1, according to priority All to y+1 x.y.z+1 All to z+1 According to priority All to y+1

• Changing the Y versions.

Bug logged in version Bug fixes Enhancement x.y.z All to z+1, for 4 months Analysis after that All to y+1 x.y+1.0 All to z+1, according to priority All to y+1

• Changing the X versions.

Bug logged in version Bug fixes Enhancement x.y.z All to z+1, for 4 months Analysis after that All to y+1, for 2 months  Analysis after that x+1.0.0 All to z+1, according to priority All to y+1

.

Subversion Quick Reference .

Setup (one time) 1. Install a Subversion client. 2. Get the Subversion config file. 3. “Check out” a working copy.

Install Subversion client TortoiseSVN is a full-featured Windows Subversion client described here. • Download and install TortoiseSVN. http://tortoisesvn.net/downloads

Get the config file The Subversion config file has settings that everyone in DevEd should use. Get our customized config file from the repository and overwrite the one on your computer. 1. In Windows Explorer, show hidden files. 2. Open the Repository Browser. Click File > TortoiseSVN > Repo-browser. 3. Enter the URL of the repository: http://sourceforge.mot.com/svnroot/ deved 4. Login using your core ID and password. 5. Browse to the file in the repository: http://sourceforge.mot.com/svnroot/ deved/tools/svn_config/trunk/src/ config 6. Right-click the config file, click Save as, and save to your Subversion folder on your local disk: <drive>:\Profiles\<coreID>\Docume nts and Settings\ <user>\Application Data\Subversion\config 7. Let Windows overwrite the file on your computer. 8. Hide hidden files. 9. Restart Windows.

“Check out” a working copy To work on files already in the repository, “check out” a folder to create a working copy of the files on your computer. 1. Create a folder on your computer. The folder can be anywhere, and you can call it whatever you want to. 2. Right-click the folder and click SVN Checkout. 3. Click the ellipses button next to the URL of repository text box. 4. In the Repository Browser, navigate to the folder you want to “check out.” Note You can check out the top-level deved folder, if you wish. But it will grow and you might not have room for it later. So check out lower-level folders when appropriate. 5. Click OK, then OK.

Routine workflow (daily) Text files: “copy-modify-merge” model Binary files: “lock-modify-unlock” model 1. Update files in your working copy. 2. Text files: edit and save. 3. Binary files: get a lock on the files, then edit and save. 4. Commit changes to files. 5. Text files: If someone else has committed a change since you last performed an update, you’ll be prompted to update your working copy, merge your changes with the head revision, and then you can commit

Update files in working copy 1. In your working copy, select the files or folders that you want the latest version of. 2. In Explorer, right-click the files or folders then click SVN Update.

Get a lock on a file Get a lock on files before you work on them if either of the following is true: • A binary file (FrameMaker, Word, PNG, GIF, etc.) • You want to prevent others from editing this file. To get a lock on a file: 1. In your working copy, locate the files to lock. 2. Right-click the selected files then click TortoiseSVN > Get lock. 3. Check the files on the list and click OK. Subversion either confirms that you got a lock or displays an error explaining why you did not get a lock. 4. Confirm that you have a lock on the files. Press F5 to refresh the display. A small lock appears on the icons of the files you have locked. If you receive an error, someone else probably has a lock on the file. Open the Repository Browser to see who has locks on what files.

Open the Repository Browser The Repository Browser shows the files on the server, and can show who has locks on what files. 1. From Windows Explorer, click File > TortoiseSVN > Repo-browser. 2. Enter the repository’s URL: http://sourceforge.mot.com/ svnroot/deved/ Or you can choose a previously entered URL. 3. Click OK. Commit changes Changes you make to files/ folders don’t appear in the repository until you commit them. 1. In your working copy, select the file or folder with the changes to commit. Selecting a folder commits all changes to that folder, and all files and folders within it recursively. 2. Right-click the files or folder then click SVN Commit. 3. Enter a log message when prompted and complete the commit operation. Important Always enter a log message when prompted. Describe what you have changed in the files. You’ll be thankful for the log messages later. TortoiseSVN shows a list of all modified files it will commit. To exclude any file’s changes from being committed, clear the checkbox next to the filename. 4. Click OK.

Add files If you need to add files to a folder, but you don’t yet have a working copy of that folder on your computer, see ““Check out” a working copy”. 1. Put the new files/folders in the correct folder within your working copy and select them. The location of the new file in your working copy is the same location it will have in the repository after you commit changes. 2. Add the files/folders. Right-click the selected files/folders then click TortoiseSVN > Add. 3. In the TortoiseSVN: Add dialog box, uncheck any files you don’t want to add and click OK. The files/folders are now under local version control but are not in the repository yet. 4. Commit changes to add the files/folders to the repository.

Revert changes You can revert changes you haven’t committed yet. • Right-click the file/folder, click TortoiseSVN > Revert , then OK. The file is now the same as when you last performed an update.

Restore earlier version You can retrieve any earlier version of a file and restore it as the head revision — for example, if you mistakenly committed changes you don’t want anymore. 1. In your working copy, browse to the file/folder you want to restore. 2. Ensure that your working copy contains the head revision of the file. If you made changes you want to keep, Commit them; if not, Revert and Update . If your file has no uncommitted changes, Update . 3. View the log. Right-click the selected file or folder then click TortoiseSVN > Show log . 4. In the log, right-click the revision you want to restore, then click Revert to this revision. After you confirm, TortoiseSVN overwrites your working copy of the file with the selected version of the file. 5. Confirm that your working copy contains the earlier version that you want. 6. Commit the change. Be sure that your log message states what revision number you’re reverting to and why.

TmL Backups and Migration

• Select component that will be migrated • Planning copies. • Talk with webmaster to discover about tags and branches from CVS. • Make backup from every branch and tags relevant in CVS. • Planning due date to migration • Planning all check-ins and no parallel development during this migration. • No patches pending during migration process.

==

Headline text

==