Changes between Initial Version and Version 1 of GettingStarted

09/07/11 15:15:41 (3 years ago)



  • GettingStarted

    v1 v1  
     1= New Developers = 
     3Welcome, new developer!  This page will help you get started using this site to help us develop Workspace (64 bit). 
     5== Getting the Code == 
     7First step is to download the Workspace (64 bit) development code.  To do this, you'll need [ Subversion], an open source version control system.  You can [ download Subversion] for all major platforms, including Linux, Windows, and MacOSX.  If you're working on Windows, the [ Tortoise SVN] package is particularly slick.  It lets you control SVN functions via right-click menus as you navigate the file system.  Subversion is similar to [ CVS], so if you've used that before, you'll feel right at home. 
     9If you're just getting started with Subversion, check out [ this tutorial] on nanoHUB. 
     11Once Subversion is installed, you can download Workspace (64 bit) as follows: 
     13% svn checkout workspace64 
     16The {{{checkout}}} command makes a local copy of the entire Workspace (64 bit) source tree into your current working directory as a subdirectory called {{{workspace64}}}.  By requesting {{{.../workspace64/svn/trunk}}}, you get the main development trunk, which should have the latest stable code. 
     18== Making Changes == 
     20Once you've downloaded the code, you can make whatever changes you like.  For example, you might edit a file to fix a bug or add some code.  To make your changes permanent, you must {{{commit}}} them to the repository as follows: 
     22% cd workspace64 
     23% svn commit --message "fixed my first bug!" 
     25You don't have to include the optional {{{--message}}} argument.  If you just say {{{svn commit}}}, Subversion will prompt you for comments in your favorite editor, and you can type much more. 
     27It's best to commit at the top of the source tree--that's why we said "{{{cd workspace64}}}" in the example above.  When you commit at the top of the tree, Subversion will search everything below, find all files that have changed, and commit them all at once.  Committing a change makes it permanent.  Once committed, other developers will see the change.  If for some reason, you want to throw away your changes and start fresh, you can simply remove your source tree and check it out all over again.  Or, you may want to remove just a few files that you've modified, and then {{{update}}} (as we'll see below) to replace the missing files with their previous version. 
     29If you want to add a new file or directory to your distribution, you can use the {{{add}}} command: 
     31% svn add README.txt 
     32% svn commit 
     34Like any other change, the file is not really added until the next {{{commit}}} operation. 
     36Similarly, if you want to remove a file or directory from your distribution, you can use the {{{delete}}} command: 
     38% svn delete README.txt 
     39% svn commit 
     41Once the change is committed, the file will disappear.  The file is still kept in the history, so it is not completely gone.  But deleting the file will take it out of your way at least for this and future versions. 
     43From time to time, you and another developer will modify the same file at the same time.  Suppose the other developer checks in his changes first.  When you try to commit, you'll get an error saying that your file is out-of-date.  In that case, you need to {{{update}}} before committing.  You can do that as follows: 
     45% cd workspace64 
     46% svn update 
     48It's best to update at the top of the source tree--just like commit.  That's why we said "{{{cd workspace64}}}" in the example above.  When you update at the top of the tree, Subversion will search everything below, adding any new files, replacing any missing files, and integrating changes made by other developers.  Once all files are properly updated, you can commit your changes again, and this time, it will work.