Subversion on MacOs X

via svnX

(NOTE: in what follow, subversion will be sometimes contracted in SVN).


  1. Download from MartinOtt Page the last updated version of SVN (it contain shell commands) and install it.
    Note that there are alternatives at Metissian, Hagberg's web pagezenzen or via the Fink software manager.
    In all cases, you must knwn the path where binaries are installed. (In the "Martin Ott" case the path is "/opt/subversion/bin", in some case the path is "/usr/local/bin" or .....).
  2. Download from SVNX the last updated version of SVNX (a graphical interface for SVN) and install it. You must insert the adequate path for the shell-command svn-client in the preferences of this application.
  3. Optionally, you can be interested in some additional tools.
    •  FileMerge is part of the Developer Tools (a 200mb download from the Developer site, once you register as a free online-only developer), and its mission is to compare two files and then merge the differences into one. FileMerge highlights the sections that differ in each file, and uses an arrow in the center area to show whether the higlighted item needs to be added to the right or left file in order to make them identical. (Here a screenshots).
    •  BibDesk is a graphical BibTeX-bibliography manager for Mac OS X. (Here a screenshots).

Utilisation of Subversion

  1. You can execute the main subverion's operation (operating on the whole working copy) by the contextual menu of the "background" of your finder open on the directory be a working copy of a project under the SVN control. While the contextual menu of a single file offers the subversion's operation on the file itself. Although SCPlugin ask often the username and password, after the first checkout, you can simple click OK without insertion of username/password. An introduction to SVN can be found here. Briefly,
    • Checkout create a working copy of an existing directory. 
    • Import insert the starting project (a set of files) on an empty repository.
    • Export extract a copy of a project in a directory (without SVN information).

    • Update try to update your working copy (it doesn't change the remote repository).
      When the server sends changes to your working copy, a letter code is displayed next to each item (file,directory) to let you know what actions svn performed to bring your working copy up-to-date:
          (U) received update from the server;
          (A) added to your working copy;
          (D) deleted from your working copy;
          (R) replaced in your working copy;
          (G) successfully merged the repository's changes into your modified copy without a problem;
          (C) conflicting changes from the server (you must use the "resolve" command described next).
    • Commit write your working copy on the remote repository.

    • Add schedule file or directory to be added to the repository. When you next commit, it will become a child of its parent directory.
    • Delete schedule file or directory to be deleted from the repository. When you commit your changes it will be removed.
    • Copy do a copy of a file.
    • Move change the place of a file under the SVN control or change its name.
    • Mkdir create a subdirectory of your project under the SVN control.

    • Status says the status of your file(s):
         (A) scheduled for add
          (C) in conflict
          (D) scheduled for deletion
          (M) modified
          (X) unversioned, but related to a svn externals definition
          (?) not under version control
          (!) under version control but is missing or somehow incomplete
          (~) mismatch of kind, for example a file in place of a directory
          (I) explicitely ignored and not under version control.
    • Revert reverts the file to its pre-modified state. It can undo any scheduled operations.
    • Resolve whenever a conflict occurs, three things typically occur to assist you in noticing and resolving that conflict:
      1) svn prints a C during the update, and remembers that the file is in a state of conflict.
      2) If svn considers the file to be of a mergable type, it places in your local file some special strings of text which delimit the conflict part into the file to visibly demonstrate the overlapping areas.
      3) for every conflicted file svn places up to 3 extra unversioned files in your working copy:
      <filename.mine> is your file as it existed in your working copy before you updated your working copy. (If  svn considers the file to be unmergeable, then the .mine file isn't created, since it would be identical to the working file)
      <filename.rOLDREV> is the file that was the  starting revision (said BASE of your local copy) on wich you  made your latest edits 
      <filename.rNEWREV> is the file that your Subversion client just received from the server when you updated your working copy (said HEAD revision of the repository).
       In order to overcome the conflict you can open the conflicting file with your preferred editor and manually modify the part of  the file looking like this:
      <<<<<<< .mine YourCHANGES ======= RepositoryCHANGES >>>>>>> .r2 .
      You can use the filemerge tool installed before, if you want.  When you have done, run resolved, and you're ready to commit your changes. You can also revert a conflicted file (in this case you don't have to run svn resolved).
    • Log shows information about the history of a file or directory.
    • Cat examines a version of a file.
    • Diff shows differences between different revision of a file.
    • List shows you what files are in a repository directory without actually downloading.
    • Cleanup searches in your working copy and runs any leftover logs, removing locks in the process.
    • Blame shows author and revision information in-line for the specified files or URLs.