Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 1 ■ SAVING YOURSELF EFFORTAgain, check for conflicts and problems; then commit the changes, and you’re done! Now, create anew branch, and get going on your next stages of development!1-14. Subversion: Merging RepositoriesTo merge two separate repositories while keeping both of their histories intact, you again need to usesvnadmin dump.■ Note If you don’t care about the history, you can just check one of them out into a working directory and thenimport that working directory as a new project into the second repository. The second repository won’t have arecord of the revision history of this newly imported project, but it will have all the current information and filecontents, and any further changes will of course be recorded as normal.The code to do this is as follows:svnadmin dump /path/to/repos1 > repos1.dumpsvnadmin dump /path/to/repos2 > repos2.dumpsvnadmin create /path/to/big_repossvn mkdir file:///path/to/big-repos repos1cat repos1.dump | svnadmin load --parent-dir repos1svn mkdir file:///path/to/big-repos repos2cat repos2.dump | svnadmin load --parent-dir repos2This works as follows: two existing repositories are dumped out, and a new repository is created thatwill hold both of them. Then the svn mkdir command is used to create a new directory within the newrepository for the first of the old repositories. This is to keep the two old repositories separate. Thesvnadmin load command is used to put the first old repository into the new one, within the specifiedparent directory. Then a directory is created for the second repository, and this is loaded into the newrepository.Again, once you’ve checked that everything is in place as expected, you can delete /path/to/repos1and /path/to/repos2 and check everything out again from the new repository.1-15. Testing: Knowing It’s a Good ThingWhether you’re implementing something new or fixing a bug, proper testing is absolutely vital. And youreally need to think of it before you start work. If you’re fixing bugs, you need to set up a test thatcurrently fails and that demonstrates the bug. If you don’t do this in advance, you can’t be certain thatyou’ve fixed the problem, because you have no baseline. This is particularly true with multiple users andmultiple machines. A reported bug may turn up only for a particular user, and if you don’t establish thatup front, you’ll think you’ve fixed it when you haven’t. Establishing a baseline test can also give youuseful information and help you narrow down the problem before you even start, as in the case of auser-specific problem. (See Chapter 11 for more on bug fixing and bug hunting.) Try to reduce the test to16Download at WoweBook.Com