CS164: Frequently Asked Questions (FAQ)

A: Please see the first-day informational handout, which is also available on web page.

A: Yes, we will post them sometime after the due date.

A: From your Unix account, log in to update server on an xterm window using ssh update. The name officially listed for your account is under the "Change your Cecos" entry.

A: Actually, any of the instructional servers will work as your Subversion server. Each working directory contains hidden files (in the subdirectories named .svn) that indicate what server contains the repository from which this working directories files came. When you commit or update, svn will go to that server, and if that server is down, the operation will fail. You can tell svn to use a different server with a command like the following (here, we'll change from the old server quasar to the new server pulsar):

    cd ~/mywork
    svn switch --relocate svn+ssh://cs61b-ta@torus.cs.berkeley.edu \
        svn+ssh://cs61b-ta@pulsar.cs.berkeley.edu

or, using Unix shell expansions:

    cd ~/mywork
    svn switch --relocate svn+ssh://cs61b-ta@{torus,pulsar}.cs.berkeley.edu

(the trailing backslash in the first variation is the shell line continuation character).

The problem with this is that our definitions of $MYREPOS, $TEAMREPOS, and $STAFFREPOS all refer to torus, and you'll run into problems if you copy stuff from a repository on one host into a working directory attached to a different one. So use svn switch temporarily, and switch back to torus as soon as it is working (we'd prefer that everyone use the same host, due to some possible file-system locking issues.)

A: One common problem is improper copying. If the commands

    cd ~/mywork/hw1
    svn commit -m "Fill in Progs.java"

are giving you grief, for example, type the command

      svn info ~/mywork/hw1

and look to see if the URL line says something like

   URL: svn+ssh://cs61b-ta@torus.cs.berkeley.edu/staff/hw1

This tell us that Subversion thinks that the working directory ~/mywork/hw1 is associated with staff/hw1 in the Subversion repository. What this tells me is that you got this directory originally with

      cd ~/mywork
      svn checkout $STAFFREPOS/hw1

Naturally, we can't allow you to modify the public files, so we've set up Subversion to deny access when you attempt to write to these files.

Instead, to copy files from our staff directory to your trunk, use

      cd ~/mywork
      svn copy $STAFFREPOS/hw1 hw1
      svn commit -m "Initial version of hw1"

If you do an 'svn info hw1' at this point, you'll see that the URL is something like URL: svn+ssh://cs61b-ta@torus.cs.berkeley.edu/cs61b-yu/hw1 That is, it's a whole new repository directory under your control.

A: This student did an svn commit and eventually got the message

  svn: Can't copy /home/cc/.../hw1/prob1.java'
  to
  /home/cc/.../svn/hw1/.svn/.../BankAccountTest.java....':
  No such file or directory

and svn status shows

  ...
  A      hw1
  !      hw1/prob1.java
  ...

That '!' means "you used to have this file under version control and now it has vanished mysteriously." Perhaps you mv'ed it or rm'd it (using the plain Unix commands of those names). Either one will do it: the files in your working directory get out of sync with what svn assumes is supposed to be there. When dealing with files A and B under version control, use

    svn move A B

instead of

    mv A B

and use

    svn remove A

instead of

    rm A

And, of course, you'll need to commit those changes at some point.

A: This is called merging in the version-control world. For the projects, we tag copies of each version of a project skeleton that is kept in repository directory .../staff/NAME in directories named tags/NAME-N, where NAME is the project designation, and the N's are sequence numbers. To update your own local version of a project with our changes, use the following steps:

1. Commit all your current work and update your directory.
2. Use the following commands to merge in changes (replace HOST appropriately). Choose the proj-N tag that represents the staff version that you are currently using (the one you checked out or last merged into your own files). For projects, we keep track of this version in a file called PUBLIC-VERSION.

       cd ~/mywork/proj2
       svn merge $STAFFREPOS/tags/proj2-N \
                 $STAFFREPOS/proj2 
   

   [Or, a better use of Unix for the second command:

       svn merge $STAFFREPOS/{tags/proj2-N,proj2} 
   

   ]
3. Use 'svn status' to see if there are any conflicts resulting from this merge (marked with a "C"). These are areas that both you and the staff changed.
   • If there are conflicts, edit each conflicted file to resolve these conflicts (you'll see them clearly marked in the file).
   • Then, for each file, FILENAME that you correct, issue the command

         svn resolved FILENAME
     

     or

         svn resolve --accept=working FILENAME
     

     to tell Subversion that this file is no longer a problem (it won't let you commit otherwise).
4. Finally, svn commit your directory.

See also our documentation on Using Subversion.

A: The problem is to import your SSH key and inform the necessary software about it. We've had two suggestions from students:

1. TortoiseSVN is an open-source Windows shell extension for Subversion. It contains a howto guide for using it with SSH.
2. SmartSVN is a graphical front-end that runs on Unix variants (including Linux and MacOS) and Windows. However, it is not free software.