From 63b87d1b549c7e5323ba520a44076e01375e280a Mon Sep 17 00:00:00 2001 From: Greg Wilson Date: Sun, 21 Apr 2013 16:29:40 -0400 Subject: [PATCH] Reverting files in version control --- svn.html | 383 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 199 insertions(+), 184 deletions(-) diff --git a/svn.html b/svn.html index dc61a4e..2c54294 100644 --- a/svn.html +++ b/svn.html @@ -1216,28 +1216,27 @@ Elara 11740 259.6528 0.008 40.0 -
+
+

Recovering Old Versions

-

Recovering Old Versions

- -
-

Understand:

-
    -
  • How to undo changes to a working copy.
    • -
  • How to recover old versions of files.
    • -
  • What a branch is.
    • -
-
+
+

Learning Objectives:

+
    +
  • Discard changes made to a working copy.
    • +
  • Recover an old version of a file.
    • +
  • Explain what branches are and when they are used.
    • +
+
-

- Now that we have seen how to merge files and resolve conflicts, - we can look at how to use version control as an "infinite undo". - Suppose that when Wolfman starts work late one night, - his copy of explore is in sync with the head at revision 12. - He decides to edit the file moons.txt; - unfortunately, he forgot that there was a full moon, - so his changes don't make a lot of sense: -

+

+ Now that we have seen how to merge files and resolve conflicts, + we can look at how to use version control as an "infinite undo". + Suppose that when Wolfman starts work late one night, + his copy of explore is in sync with the head at revision 12. + He decides to edit the file moons.txt; + unfortunately, he forgot that there was a full moon, + so his changes don't make a lot of sense: + 

 Just one moon can make me growl
@@ -1245,35 +1244,35 @@ Four would make me want to howl
 ...
-

- When he's back in human form the next day, - he wants to undo his changes. - Without version control, his choices would be grim: - he could try to edit them back into their original state by hand - (which for some reason hardly ever seems to work), - or ask his colleagues to send him their copies of the files - (which is almost as embarrassing as chasing the neighbor's cat when in wolf form). -

+

+ When he's back in human form the next day, + he wants to undo his changes. + Without version control, his choices would be grim: + he could try to edit them back into their original state by hand + (which for some reason hardly ever seems to work), + or ask his colleagues to send him their copies of the files + (which is almost as embarrassing as chasing the neighbor's cat when in wolf form). +

-

- Since he's using Subversion, though, - and hasn't committed his work to the repository, - all he has to do is revert his local changes. - svn revert simply throws away local changes to files - and puts things back the way they were before those changes were made. - This is a purely local operation: - since Subversion stores the history of the project inside every working copy, - Wolfman doesn't need to be connected to the network to do this. -

+

+ Since he's using Subversion, though, + and hasn't committed his work to the repository, + all he has to do is revert his local changes. + svn revert simply throws away local changes to files + and puts things back the way they were before those changes were made. + This is a purely local operation: + since Subversion stores the history of the project inside every working copy, + Wolfman doesn't need to be connected to the network to do this. +

-

- To start, - Wolfman uses svn diff without the -r HEAD flag - to take a look at the differences between his file - and the master copy in the repository. - Since he doesn't want to keep his changes, - his next command is svn revert moons.txt. -

+

+ To start, + Wolfman uses svn diff without the -r HEAD flag + to take a look at the differences between his file + and the master copy in the repository. + Since he doesn't want to keep his changes, + his next command is svn revert moons.txt. + 

 $ cd jupiter
@@ -1281,13 +1280,13 @@ $ svn revert moons.txt
 Reverted   moons.txt
-

- What if someone has committed their changes, - but still wants to undo them? - For example, - suppose Dracula decides that the numbers in moons.txt would look better with commas. - He edits the file to put them in: -

+

+ What if someone has committed their changes, + but still wants to undo them? + For example, + suppose Dracula decides that the numbers in moons.txt would look better with commas. + He edits the file to put them in: + 

 Name            Orbital Radius  Orbital Period  Mass            Radius
@@ -1301,47 +1300,49 @@ Himalia      11,460           250.5662
 Elara        11,740           259.6528            0.008           40.0
-

- then commits his changes to create revision 13. - A little while later, - the Mummy sees the change and orders Dracula to put things back the way they were. - What should Dracula do? -

+

+ then commits his changes to create revision 13. + A little while later, + the Mummy sees the change and orders Dracula to put things back the way they were. + What should Dracula do? +

-

- We can draw the sequence of events leading up to revision 13 - as shown in Fixture XXX: -

+

+ We can draw the sequence of events leading up to revision 13 + as shown in Fixture 12: +

-
- Before Undoing -
+
+ Before Undoing +
Figure 12: Before Undoing
+
-

- Dracula wants to erase revision 13 from the repository, - but he can't actually do that: - once a change is in the repository, - it's there forever. - What he can do instead is merge the old revision with the current revision - to create a new revision - (Fixture XXX). -

+

+ Dracula wants to erase revision 13 from the repository, + but he can't actually do that: + once a change is in the repository, + it's there forever. + What he can do instead is merge the old revision with the current revision + to create a new revision + (Fixture 13). +

-
- Merging History -
+
+ Merging History +
Figure 13: Merging History
+
-

- This is exactly like merging changes made by two different people; - the only difference is that the "other person" is his past self. -

+

+ This is exactly like merging changes made by two different people; + the only difference is that the "other person" is his past self. +

-

- To undo his commas, - Dracula must merge revision 12 (the one before his change) - with revision 13 (the current head revision) - using svn merge: -

+

+ To undo his commas, + Dracula must merge revision 12 (the one before his change) + with revision 13 (the current head revision) + using svn merge: + 

 $ svn merge -r HEAD:12 moons.txt
@@ -1349,111 +1350,125 @@ $ svn merge -r HEAD:12 moons.txt
 U  moons.txt
-

- The -r flag specifies the range of revisions to merge: - to undo the changes from revision 12 to revision 13, - he uses either 13:12 or HEAD:12 - (since he is going backward in time from the most recent revision to revision 12). - This is called a reverse merge - because he's going backward in time. -

+

+ The -r flag specifies the range of revisions to merge: + to undo the changes from revision 12 to revision 13, + he uses either 13:12 or HEAD:12 + (since he is going backward in time from the most recent revision to revision 12). + This is called a reverse merge + because he's going backward in time. +

-

- After he runs this command, - he must run svn commit to save the changes to the repository. - This creates a new revision, number 14, - rather than erasing revision 13. - That way, - the changes he made to create revision 13 are still there - if he can ever convince the Mummy that numbers should have commas. -

+

+ After he runs this command, + he must run svn commit to save the changes to the repository. + This creates a new revision, number 14, + rather than erasing revision 13. + That way, + the changes he made to create revision 13 are still there + if he can ever convince the Mummy that numbers should have commas. +

-

- Merging can be used to recover older revisions of files, - not just the most recent, - and to recover many files or directories at a time. - The most frequent use, though, - is to manage parallel streams of development in large projects. - This is outside the scope of this chapter, - but the basic idea is simple. -

+

+ Merging can be used to recover older revisions of files, + not just the most recent, + and to recover many files or directories at a time. + The most frequent use, though, + is to manage parallel streams of development in large projects. + This is outside the scope of this chapter, + but the basic idea is simple. +

-

- Suppose that Universal Monsters has just released a new program for designing secret lairs. - Dracula and Wolfman are supposed to start adding a few features - that had to be left out of the first release because time ran short. - At the same time, - Frankenstein and the Mummy are doing technical support: - their job is to fix any bugs that users find. - All sorts of things could go wrong if both teams tried to work on the same code at the same time. - For example, - if Frankenstein fixed a bug and sent a new copy of the program to a user in Greenland, - it would be all too easy for him to accidentally include - the half-completed shark tank control feature that Wolfman was working on. -

+

+ Suppose that Universal Missions has just released a new program + for designing interplanetary voyages. + Dracula and Wolfman are supposed to add some features + that were left out of the first release because time ran short. + At the same time, + Frankenstein and the Mummy are doing technical support: + their job is to fix any bugs that users find. +

-

- The usual way to handle this situation is - to create a branch - in the repository for each major sub-project - (Figure XXX). - While Wolfman and Dracula work on - the main line, - Frankenstein and the Mummy create a branch, - which is just another copy of the repository's files and directories - that is also under version control. - They can work in their branch without disturbing Wolfman and Dracula and vice versa: -

+

+ All sorts of things could go wrong + if both teams tried to work on the same code at the same time. + In particular, + Dracula and Wolfman might want to make large changes + to the structure of the code + in order to make it easier to add new features, + while Frankenstein and the Mummy want to make as few changes as possible + so as not to introduce new bugs while fixing old ones. +

-
- Branching and Merging -
+

+ The usual way to handle this situation is + to create a branch + in the repository for each major sub-project + (Figure 14). + While Wolfman and Dracula work on + the main line, + Frankenstein and the Mummy create a branch, + which is just another copy of the repository's files and directories + that is also under version control. + They can work in their branch without disturbing Wolfman and Dracula and vice versa: +

-

- Branches in version control repositories are often described as "parallel universes". - Each branch starts off as a clone of the project at some moment in time - (typically each time the software is released, - or whenever work starts on a major new feature). - Changes made to a branch only affect that branch, - just as changes made to the files in one directory don't affect files in other directories. - However, - the branch and the main line are both stored in the same repository, - so their revision numbers are always in step. -

+
+ Branching and Merging +
Figure 14: Branching and Merging
+
-

- If someone decides that a bug fix in one branch should also be made in another, - all they have to do is merge the files in question. - This is exactly like merging an old version of a file with the current one, - but instead of going backward in time, - the change is brought sideways from one branch to another. -

+

+ Branches in version control repositories are often described as "parallel universes". + Each branch starts off as a clone of the project at some moment in time + (typically each time the software is released, + or whenever work starts on a major new feature). + Changes made to a branch only affect that branch, + just as changes made to the files in one directory don't affect files in other directories. + However, + the branch and the main line are both stored in the same repository, + so their revision numbers are always in step. +

-

- Branching helps projects scale up by letting sub-teams work independently, - but too many branches can cause as many problems as they solve. - Karl Fogel's excellent book - Producing Open Source Software, - and Laura Wingerd and Christopher Seiwald's paper - "High-level Best Practices in Software Configuration Management", - talk about branches in much more detail. - Projects usually don't need to do this until they have a dozen or more developers, - or until several versions of their software are in simultaneous use, - but using branches is a key part of switching from software carpentry to software engineering. -

+

+ If someone decides that a bug fix in one branch should also be made in another, + all they have to do is merge the files in question. + This is exactly like merging an old version of a file with the current one, + but instead of going backward in time, + the change is brought sideways from one branch to another. +

-
-

Summary

-
    -
  • 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.
    • -
-
+

+ Branching helps projects scale up by letting sub-teams work independently, + but too many branches can cause as many problems as they solve. + Karl Fogel's excellent book + Producing Open Source Software, + and Laura Wingerd and Christopher Seiwald's paper + "High-level Best Practices in Software Configuration Management", + talk about branches in much more detail. + Projects usually don't need to do this until they have a dozen or more developers, + or until several versions of their software are in simultaneous use, + but using branches is a key part of switching from software carpentry to software engineering. +

-
+
+

Summary

+
    +
  • 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.
    • +
+
+ +
+

Challenges

+ +

write some

+
+ +
-- 2.26.2