From cc352b48e8d0d62f1bf4e379a16c07372c81ef90 Mon Sep 17 00:00:00 2001 From: Greg Wilson Date: Mon, 22 Apr 2013 06:24:40 -0400 Subject: [PATCH] A little more tidy-up --- svn.html | 697 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 380 insertions(+), 317 deletions(-) diff --git a/svn.html b/svn.html index 21f82f3..3a02b0e 100644 --- a/svn.html +++ b/svn.html @@ -311,7 +311,7 @@ cydonia.txt mons-olympus.txt 
 $ pwd
-/home/vlad/explore
+/home/dracula/explore
 $ ls -a
 .    ..    .svn    earth    jupiter    mars
 $ ls -F .svn
@@ -1369,6 +1369,33 @@ U  moons.txt
     if he can ever convince the Mummy that numbers should have commas.
   

 
+  

+    
Another Way to Do It

+
+    

+      Another way to recover a particular version of a particular file
+      is to use the svn copy command.
+      If the URL of our repository is
+      https://universal.software-carpentry.org/explore,
+      then the command:
+    

+
+
+$ svn copy https://universal.software-carpentry.org/explore/mission.txt@120 ./mission.txt
+

+
+    

+      copies the file mission.txt as it was in revision 120
+      into our working directory
+      (overwriting whatever mission.txt file we currently have,
+      if any).
+      What's more,
+      using svn copy brings along the file's history as well,
+      so that future svn log operations will show
+      how mission.txt was resurrected.
+    

+  

+
   

     Merging can be used to recover older revisions of files,
     not just the most recent,
@@ -1457,105 +1484,121 @@ U  moons.txt
       
  • Old versions of files can be recovered by merging their old state with their current state.
    • 
       
  • Recovering an old version of a file does not erase the intervening changes.
    • 
       
  • Use branches to support parallel independent development.
    • 
-      
  • svn merge merges two revisions of a file.
    • 
       
  • svn revert undoes local changes to files.
    • 
+      
  • svn merge merges two revisions of a file.
    • 
     
   
 
   
    
     
    Challenges
    
 
-    
    write some
    
+    
      
+      
    1. 
+        Explain what the command:
+
      +svn diff -r 240:261 fish.dat
+
      
+        does, and when you might want to run it.
+      
      2. 
+
+      
    2. 
+        Suppose that a file called mission.txt
+        existed in revision 90 of a repository,
+        but had been deleted in revision 91.
+        What two commands could we use to recover it?
+      
      3. 
+
+    
    
   
    
 
 
 
-    
    
+
    
+  
    Setting up a Repository
    
 
-      
    Setting up a Repository
    
+  
    
+    
    Learning Objectives
    
+    
      
+      
    • How to create a repository.
      • 
+    
    
+  
    
 
-      
    
-        
    Understand:
    
-        
      
-          
    • How to create a repository.
      • 
-        
    
-      
    
+  
    
+    It is finally time to see how to create a repository.
+    As a quick recap,
+    we will keep the master copy of our work in a repository
+    on a server that we can access from other machines on the internet.
+    That master copy consists of files and directories that no-one ever edits directly.
+    Instead, a copy of Subversion running on that machine
+    manages updates for us and watches for conflicts.
+    Our working copy is a mirror image of the master sitting on our computer.
+    When our Subversion client needs to communicate with the master,
+    it exchanges data with the copy of Subversion running on the server.
+  
    
+
+  
    
+    What's Needed for a Repository
+    
    Figure 15: What's Needed for a Repository
    
+  
    
 
-      
    
-        It is finally time to see how to create a repository.
-        As a quick recap,
-        we will keep the master copy of our work in a repository
-        on a server that we can access from other machines on the internet.
-        That master copy consists of files and directories that no-one ever edits directly.
-        Instead, a copy of Subversion running on that machine
-        manages updates for us and watches for conflicts.
-        Our working copy is a mirror image of the master sitting on our computer.
-        When our Subversion client needs to communicate with the master,
-        it exchanges data with the copy of Subversion running on the server.
-      
    
+  
    
+    To make this to work, we need four things
+    (Figure 15):
+  
    
 
-      
    
-        What's Needed for a Repository
-      
    
+  
      
 
-      
      
-        To make this to work, we need four things
-        (Figure XXX):
-      
      
+    
    1. 
+      The repository itself.
+      It's not enough to create an empty directory and start filling it with files:
+      Subversion needs to create a lot of other structure
+      in order to keep track of old revisions, who made what changes, and so on.
+    
      2. 
 
-      
        
-
-        
      1. 
-          The repository itself.
-          It's not enough to create an empty directory and start filling it with files:
-          Subversion needs to create a lot of other structure
-          in order to keep track of old revisions, who made what changes, and so on.
-        
        2. 
-
-        
      2. 
-          The full URL of the repository.
-          This includes the URL of the server
-          and the path to the repository on that machine.
-          (The second part is needed because a single server can,
-          and usually will,
-          host many repositories.)
-        
        3. 
-
-        
      3. 
-          Permission to read or write the master copy.
-          Many open source projects give the whole world permission to read from their repository,
-          but very few allow strangers to write to it:
-          there are just too many possibilities for abuse.
-          Somehow, we have to set up a password or something like it
-          so that users can prove who they are.
-        
        4. 
-
-        
      4. 
-          A working copy of the repository on our computer.
-          Once the first three things are in place,
-          this just means running the checkout command.
-        
        5. 
-
-      
      
+    
    2. 
+      The full URL of the repository.
+      This includes the URL of the server
+      and the path to the repository on that machine.
+      (The second part is needed because a single server can,
+      and usually will,
+      host many repositories.)
+    
      3. 
 
-      
      
-        To keep things simple,
-        we will start by creating a repository on the machine that we're working on.
-        This won't let us share our work with other people,
-        but it will allow us to save the history of our work as we go along.
-      
      
+    
    3. 
+      Permission to read or write the master copy.
+      Many open source projects give the whole world permission to read from their repository,
+      but very few allow strangers to write to it:
+      there are just too many possibilities for abuse.
+      Somehow, we have to set up a password or something like it
+      so that users can prove who they are.
+    
      4. 
 
-      
      
-        The command to create a repository is svnadmin create,
-        followed by the path to the repository.
-        If we want to create a repository called lair_repo
-        directly under our home directory,
-        we just cd to get home
-        and run svnadmin create lair_repo.
-        This command creates a directory called lair_repo to hold our repository,
-        and fills it with various files that Subversion uses
-        to keep track of the project's history:
-      
      
+    
    4. 
+      A working copy of the repository on our computer.
+      Once the first three things are in place,
+      this just means running the checkout command.
+    
      5. 
+
+  
    
+
+  
    
+    To keep things simple,
+    we will start by creating a repository on the machine that we're working on.
+    This won't let us share our work with other people,
+    but it will allow us to save the history of our work as we go along.
+  
    
+
+  
    
+    The command to create a repository is svnadmin create,
+    followed by the path to the repository.
+    If we want to create a repository called lair_repo
+    directly under our home directory,
+    we just cd to get home
+    and run svnadmin create lair_repo.
+    This command creates a directory called lair_repo to hold our repository,
+    and fills it with various files that Subversion uses
+    to keep track of the project's history:
+  
    
 
 
     $ cd
@@ -1564,259 +1607,274 @@ $ ls -F lair_repo
 README.txt    conf/    db/    format    hooks/    locks/
 
    
 
-      
    
-        We should never edit anything in this repository directly.
-        Doing so probably won't shred our sanity and leave us gibbering in mindless horror,
-        but it will almost certainly make the repository unusable.
-      
    
+  
    
+    We should never edit any of this directly,
+    since it will almost certainly make the repository unusable.
+    Instead,
+    we should use svn checkout
+    to get a working copy of this repository.
+    If our home directory is /users/mummy,
+    then the full path to the repository we just created is /users/mummy/lair_repo,
+    so we run svn checkout file:///users/mummy/lair lair_working.
+  
    
 
-      
    
-        To get a working copy of this repository,
-        we use Subversion's checkout command.
-        If our home directory is /users/mummy,
-        then the full path to the repository we just created is /users/mummy/lair_repo,
-        so we run svn checkout file:///users/mummy/lair lair_working.
-      
    
+  
    
+    Working backward,
+    the second argument,
+    lair_working,
+    specifies where the working copy is to be put.
+    The first argument is the URL of our repository,
+    and it has two parts.
+    /users/mummy/lair_repo is the path to repository directory.
+    file:// specifies the protocol
+    that Subversion will use to communicate with the repository—in this case,
+    it says that the repository is part of the local machine's filesystem.
+    (Notice that the protocol ends in two slashes,
+    while the absolute path to the repository starts with a slash,
+    making three in total.
+    A very common mistake is to type only two, since that's what web URLs normally have.)
+  
    
 
-      
    
-        Working backward,
-        the second argument,
-        lair_working,
-        specifies where the working copy is to be put.
-        The first argument is the URL of our repository,
-        and it has two parts.
-        /users/mummy/lair_repo is the path to repository directory.
-        file:// specifies the protocol
-        that Subversion will use to communicate with the repository—in this case,
-        it says that the repository is part of the local machine's filesystem.
-        Notice that the protocol ends in two slashes,
-        while the absolute path to the repository starts with a slash,
-        making three in total.
-        A very common mistake is to type only two, since that's what web URLs normally have.
-      
    
+  
    
+    When we're doing a checkout,
+    it is very important that we provide the second argument,
+    which specifies the name of the directory we want the working copy to be put in.
+    Without it,
+    Subversion will try to use the name of the repository,
+    lair_repo,
+    as the name of the working copy.
+    Since we're in the directory that contains the repository,
+    this means that Subversion will try to overwrite the repository with a working copy.
+    Again,
+    there isn't much risk of our sanity being torn to shreds,
+    but this could ruin our repository.
+  
    
 
-      
    
-        When we're doing a checkout,
-        it is very important that we provide the second argument,
-        which specifies the name of the directory we want the working copy to be put in.
-        Without it,
-        Subversion will try to use the name of the repository,
-        lair_repo,
-        as the name of the working copy.
-        Since we're in the directory that contains the repository,
-        this means that Subversion will try to overwrite the repository with a working copy.
-        Again,
-        there isn't much risk of our sanity being torn to shreds,
-        but this could ruin our repository.
-      
    
+  
    
+    To avoid this problem,
+    most people create a sub-directory in their account called something like repos,
+    and then create their repositories in that.
+    For example,
+    we could create our repository in /users/mummy/repos/lair,
+    then check out a working copy as /users/mummy/lair.
+    This practice makes both names easier to read.
+  
    
 
-      
    
-        To avoid this problem,
-        most people create a sub-directory in their account called something like repos,
-        and then create their repositories in that.
-        For example,
-        we could create our repository in /users/mummy/repos/lair,
-        then check out a working copy as /users/mummy/lair.
-        This practice makes both names easier to read.
-      
    
+  
    HERE
    
 
-      
    
-        The obvious next steps are
-        to put our repository on a server,
-        rather than on our personal machine,
-        and to give other people access to the repository we have just created
-        so that they can work with us.
-        We'll discuss the first in a later chapter,
-        but unfortunately,
-        the second really does require things that we are not going to cover in this course.
-        If you want to do this, you can:
-      
    
+  
    
+    The obvious next steps are
+    to put our repository on a server,
+    rather than on our personal machine,
+    and to give other people access to the repository we have just created
+    so that they can work with us.
+    We should always keep repositories on a different machine than
+    the one we're using for day-to-day work
+    so that if the latter is lost or damaged,
+    we still have our master copy.
+  
    
+
+  
    
+    The second step—sharing the repository with others—requires
+    skills that we are deliberately not going to cover.
+    As we discuss in the lessons on web programming,
+    as soon as you make something available over the internet,
+    you open up a channel for attack.
+  
    
+
+  
    
+    If you want to do this, you can:
+  
    
 
-      
      
+  
        
 
-        
      • 
-          ask your system administrator to set it up for you;
-        
        • 
+    
      • 
+      ask your system administrator to set it up for you;
+    
        • 
 
-        
      • 
-          use an open source hosting service like SourceForge,
-          Google Code,
-          GitHub,
-          or BitBucket; or
-        
        • 
+    
      • 
+      use an open source hosting service like SourceForge,
+      Google Code,
+      GitHub,
+      or BitBucket; or
+    
        • 
 
-        
      • 
-          spend a few dollars a month on a commercial hosting service like DreamHost
-          that provides web-based GUIs for creating and managing repositories.
-        
        • 
+    
      • 
+      spend a few dollars a month on a commercial hosting service like DreamHost
+      that provides web-based GUIs for creating and managing repositories.
+    
        • 
 
-      
      
+  
    
 
-      
    
-        If you choose the second or third option,
-        please check with whoever handles intellectual property at your institution
-        to make sure that putting your work on a commercially-operated machine
-        that is probably in some other legal jurisdiction
-        isn't going to cause trouble.
-        Many people assume that it's "just OK",
-        while others act as if not having asked will be an acceptable defence later on.
-        Unfortunately,
-        neither is true…
-      
    
+  
    
+    If you choose the second or third option,
+    please check with whoever handles intellectual property at your institution
+    to make sure that putting your work on a commercially-operated machine
+    that is probably in some other legal jurisdiction
+    isn't going to cause trouble.
+    Many people assume that it's "just OK",
+    while others act as if not having asked will be an acceptable defence later on.
+    Unfortunately,
+    neither is true…
+  
    
 
-      
    
-        
    Summary
    
-        
      
-          
    • Repositories can be hosted locally, on local (departmental) servers, on hosting services, or on their owners' own domains.
      • 
-          
    • svnadmin create name creates a new repository.
      • 
-        
    
-      
    
+  
    
+    
    Summary
    
+    
      
+      
    • Repositories can be hosted locally, on local (departmental) servers, on hosting services, or on their owners' own domains.
      • 
+      
    • svnadmin create name creates a new repository.
      • 
+    
    
+  
    
 
-    
    
+  
    
+    
    Challenges
    
+    
    write some
    
+  
    
 
-    
    
+
    
 
-      
    Provenance
    
+
    
+  
    Provenance
    
 
-      
    
-        
    Understand:
    
-        
      
-          
    • What data provenance is.
      • 
-          
    • How to embed version numbers and other information in files managed by version control.
      • 
-          
    • How to record version information about a program in its output.
      • 
-        
    
-      
    
+  
    
+    
    Understand:
    
+    
      
+      
    • What data provenance is.
      • 
+      
    • How to embed version numbers and other information in files managed by version control.
      • 
+      
    • How to record version information about a program in its output.
      • 
+    
    
+  
    
 
-      
    
-        In art,
-        the provenance of a work
-        is the history of who owned it, when, and where.
-        In science,
-        it's the record of how a particular result came to be:
-        what raw data was processed by what version of what program to create which intermediate files,
-        what was used to turn those files into which figures of which papers,
-        and so on.
-      
    
+  
    
+    In art,
+    the provenance of a work
+    is the history of who owned it, when, and where.
+    In science,
+    it's the record of how a particular result came to be:
+    what raw data was processed by what version of what program to create which intermediate files,
+    what was used to turn those files into which figures of which papers,
+    and so on.
+  
    
 
-      
    
-        One of the central ideas of this course is that
-        wen can automatically track the provenance of scientific data.
-        To start,
-        suppose we have a text file combustion.dat in a Subversion repository.
-        Run the following two commands:
-      
    
+  
    
+    One of the central ideas of this course is that
+    wen can automatically track the provenance of scientific data.
+    To start,
+    suppose we have a text file combustion.dat in a Subversion repository.
+    Run the following two commands:
+  
    
 
 
     $ svn propset svn:keywords Revision combustion.dat
 $ svn commit -m "Turning on the 'Revision' keyword" combustion.dat
 
    
 
-      
    
-        Now open the file in an editor
-        and add the following line somewhere near the top:
-      
    
+  
    
+    Now open the file in an editor
+    and add the following line somewhere near the top:
+  
    
 
 
     # $Revision:$
 
    
 
-      
    
-        The '#' sign isn't important:
-        it's just what .dat files use to show comments.
-        The $Revision:$ string,
-        on the other hand,
-        means something special to Subversion.
-        Save the file, and commit the change:
-      
    
+  
    
+    The '#' sign isn't important:
+    it's just what .dat files use to show comments.
+    The $Revision:$ string,
+    on the other hand,
+    means something special to Subversion.
+    Save the file, and commit the change:
+  
    
 
 
     $ svn commit -m "Inserting the 'Revision' keyword" combustion.dat
 
    
 
-      
    
-        When we open the file again,
-        we'll see that Subversion has changed that line to something like:
-      
    
+  
    
+    When we open the file again,
+    we'll see that Subversion has changed that line to something like:
+  
    
 
 
     # $Revision: 143$
 
    
 
-      
    
-        i.e., Subversion has inserted the version number
-        after the colon and before the closing $.
-      
    
+  
    
+    i.e., Subversion has inserted the version number
+    after the colon and before the closing $.
+  
    
 
-      
    
-        Here's what just happened.
-        First, Subversion allows you to set
-        properties
-        for files and and directories.
-        These properties aren't in the files or directories themselves,
-        but live in Subversion's database.
-        One of those properties,
-        svn:keywords,
-        tells Subversion to look in files that are being changed
-        for strings of the form $propertyname: …$,
-        where propertyname is a string like Revision or Author.
-        (About half a dozen such strings are supported.)
-      
    
+  
    
+    Here's what just happened.
+    First, Subversion allows you to set
+    properties
+    for files and and directories.
+    These properties aren't in the files or directories themselves,
+    but live in Subversion's database.
+    One of those properties,
+    svn:keywords,
+    tells Subversion to look in files that are being changed
+    for strings of the form $propertyname: …$,
+    where propertyname is a string like Revision or Author.
+    (About half a dozen such strings are supported.)
+  
    
 
-      
    
-        If it sees such a string,
-        Subversion rewrites it as the commit is taking place to replace …
-        with the current version number,
-        the name of the person making the change,
-        or whatever else the property's name tells it to do.
-        You only have to add the string to the file once;
-        after that,
-        Subversion updates it for you every time the file changes.
-      
    
+  
    
+    If it sees such a string,
+    Subversion rewrites it as the commit is taking place to replace …
+    with the current version number,
+    the name of the person making the change,
+    or whatever else the property's name tells it to do.
+    You only have to add the string to the file once;
+    after that,
+    Subversion updates it for you every time the file changes.
+  
    
 
-      
    
-        Putting the version number in the file this way can be pretty handy.
-        If you copy the file to another machine,
-        for example,
-        it carries its version number with it,
-        so you can tell which version you have even if it's outside version control.
-        We'll see some more useful things we can do with this information in
-        the next chapter.
-      
    
+  
    
+    Putting the version number in the file this way can be pretty handy.
+    If you copy the file to another machine,
+    for example,
+    it carries its version number with it,
+    so you can tell which version you have even if it's outside version control.
+    We'll see some more useful things we can do with this information in
+    the next chapter.
+  
    
 
-      
    
-
-        
    When Not to Use Version Control
    
-
-        
    
-          Despite the rapidly decreasing cost of storage,
-          it is still possible to run out of disk space.
-          In some labs,
-          people can easy go through 2 TB/month if they're not careful.
-          Since version control tools usually store revisions in terms of lines,
-          with binary data files,
-          they end up essentially storing every revision separately.
-          This isn't that bad
-          (it's what we'd be doing anyway),
-          but it means version control isn't doing what it likes to do,
-          and the repository can get very large very quickly.
-          Another concern is that if very old data will no longer be used,
-          it can be nice to archive or delete old data files.
-          This is not possible if our data is version controlled:
-          information can only be added to a repository,
-          so it can only ever increase in size.
-        
    
-
-      
    
+  
    
+    
    When Not to Use Version Control
    
 
-      
    
-        We can use this trick with shell scripts too,
-        or with almost any other kind of program.
-        Going back to Nelle Nemo's data processing from the previous chapter,
-        for example,
-        suppose she writes a shell script that uses gooclean
-        to tidy up data files.
-        Her first version looks like this:
-      
    
+    
    
+      Despite the rapidly decreasing cost of storage,
+      it is still possible to run out of disk space.
+      In some labs,
+      people can easy go through 2 TB/month if they're not careful.
+      Since version control tools usually store revisions in terms of lines,
+      with binary data files,
+      they end up essentially storing every revision separately.
+      This isn't that bad
+      (it's what we'd be doing anyway),
+      but it means version control isn't doing what it likes to do,
+      and the repository can get very large very quickly.
+      Another concern is that if very old data will no longer be used,
+      it can be nice to archive or delete old data files.
+      This is not possible if our data is version controlled:
+      information can only be added to a repository,
+      so it can only ever increase in size.
+    
    
+
+  
    
+
+  
    
+    We can use this trick with shell scripts too,
+    or with almost any other kind of program.
+    Going back to Nelle Nemo's data processing from
+    the lesson on the shell,
+    for example,
+    suppose she writes a shell script that uses gooclean
+    to tidy up data files.
+    Her first version looks like this:
+  
    
 
 
     for filename in $*
@@ -1825,13 +1883,13 @@ do
 done
 
    
 
-      
    
-        i.e., it runs gooclean with bounding values of 0 and 100
-        for each specified file,
-        putting the result in a temporary file with a well-defined name.
-        Assuming that '#' is the comment character for those kinds of data files,
-        she could instead write:
-      
    
+  
    
+    i.e., it runs gooclean with bounding values of 0 and 100
+    for each specified file,
+    putting the result in a temporary file with a well-defined name.
+    Assuming that '#' is the comment character for those kinds of data files,
+    she could instead write:
+  
    
 
 
     for filename in $*
@@ -1841,28 +1899,33 @@ do
 done
 
    
 
-      
    
-        The first change puts a line in the output file
-        that describes how that file was created.
-        The second change is to use >> instead of >
-        to redirect gooclean's output to the file.
-        >> means "append to":
-        instead of overwriting whatever is in the file,
-        it adds more content to it.
-        This ensures that the first line of the file is the provenance record,
-        with the actual output of gooclean after it.
-      
    
+  
    
+    The first change puts a line in the output file
+    that describes how that file was created.
+    The second change is to use >> instead of >
+    to redirect gooclean's output to the file.
+    >> means "append to":
+    instead of overwriting whatever is in the file,
+    it adds more content to it.
+    This ensures that the first line of the file is the provenance record,
+    with the actual output of gooclean after it.
+  
    
 
-      
    
-        
    Summary
    
-        
      
-          
    • $Keyword:$ in a file can be filled in with a property value each time the file is committed.
      • 
-          
    • Put version numbers in programs' output to establish provenance for data.
      • 
-          
    • svn propset svn:keywords property files tells Subversion to start filling in property values.
      • 
-        
    
-      
    
+  
    
+    
    Summary
    
+    
      
+      
    • $Keyword:$ in a file can be filled in with a property value each time the file is committed.
      • 
+      
    • Put version numbers in programs' output to establish provenance for data.
      • 
+      
    • svn propset svn:keywords property files tells Subversion to start filling in property values.
      • 
+    
    
+  
    
 
-    
    
+  
    
+    
    Challenges
    
+    
    write some
    
+  
    
+
+
    
 
 
    
   
    Summing Up
    
-- 
2.26.2