Web Site
Developers
Regaining Control of Subversion-II
Unexpected Further Words
At the end of the last article, I really thought I had covered this topic thoroughly. Nonetheless, I had a chilling recognition just as I was about to commit my working copy of the site's source code that I was about to place critical files into a version control prematurely. How did this happen? It can be most easily explained by an unnatural combination of sloth and being over conscientious.
The sloth part you know, I was being lazy. I was over zealous last time too, however, this time it was a bit different. Again I brought files into the source control system from the server, however, this time it was driven by my desire to merge the last change of the style sheet that went into production rapidly with the under test version that was to go in the next week. Now each had a differing underlying code base. However, unlike the previous instances where an early presence of a file caused no harm, this time the wrong code would be introduced without complaint.
To make matters worse, I down loaded the front pages off the server - good move, then I altered them by adding new story and adjusted the contents of both pages. An action I would regret. Now I was in danger of committing multiple file revisions prematurely. The core problem is that each of the named files already exists in the source control system, hence, each is seen as a modified file. Therefore, any commit will put these files into the next revision. That is exactly the problem I wanted to avoid. Thus, the discussion is how to extricate myself from such a situation, albeit self inflicted.
Mistakes Were Made
The initial step was external to the version control system when the bash diff command yielded less satisfactory results comparing the working copy to the still external test version of the css file:
:~/OST-1$ diff css/style-sheet.css ../Documents/Selected-Files/style-sheet-test4.css
< /* color: #1E90FF; On server value*/
< color: #6058cd; /* test - better blue */
> color: #6058cd; /* better blue */
34a34,39
> /* New 7/24/07 */
> #page-two {
> font-size: 120%;
> text-align: center;
> color: #0000ff;
> }
44,51d48
< /* Special h3 heading, enlarged font
< red to identify news content */
< #central-grouping-news {
< text-align: center;
< color: #cb1741;
< font-size: 110%;
< }
<
192d188
< /* color: #000000; */
195,197d190
< /* border-right-style: solid;
< border-right-color: #b22222;
< border-right-width: 8px; */
205c198
< width: 55%;
> width: 56%;
210c203
< border-left-width: 8px;
> border-left-width: thick;
213c206
< border-right-width: 8px;
> border-right-width: thick;
216c209
< border-fit: auto;
> /* border-fit: auto; */
220a214
> /* Candidate for removal, once gone from all pages */
222,224d215
< /* border-left: thick; */
< /* padding-left: 10px; */
< /* padding-right: 10px; */
237c228,229
< border-right-width: 8px;
> border-right-width: 8px; /* leaving value for visual
> seeing pages with old style */
...
There is much more. Despite my attempt to put note and breaks between portions of the output, I still found myself confused and worried by seemingly missing lines of code. That is when my preference for the Subversion diff overrode any residual good sense. I assume I was fatigued. I further compounded my error by renaming the test version simply style-sheet.css. Had I used a differing name no real harm would have been caused. Nonetheless, I made one more effort with bash and remained confused. However, ultimately the problem was my own, since I had forgotten that I had already altered the test version to include the news-bands that seemed so conspicuously absent in the output of the bash diff. Moreover, even when I ran the Subversion diff I still was not cognizant of that action:
:~/OST-1$ svn diff css/style-sheet.css
Index: css/style-sheet.css
===================================================================
--- css/style-sheet.css (revision 3)
+++ css/style-sheet.css (working copy)
...
#news-bands {
position: relative;
text-align: justify;
font-size: 11pt;
- width: 99%;
+ width: 98%;
height: auto;
min-height: 50px;
background-color: #ADD8E6;
color: #000000;
- padding-left: .5%;
- padding-right: .5%;
+ padding-left: 1.0%;
+ padding-right: 1.0%;
border-top-style: solid;
border-top-color: #000000;
border-top-width: 3px;
...
I am concentrating on this portion, because as mentioned I was at a loss at why I wasn't seeing this section of the code showing in the bash diff. As it is obvious here, it was present but not easily discerned. The bash diff shows fewer lines. Moreover, I still missed the major point that I had already altered the test style sheet, which gives some idea of my mental state. That is, for whatever reason doing a commit just prior to the hectic endeavor of publishing site changes places too much pressure in too short a period. Thus, my now working toward commits just after the site has a major revision.
At this point I was oblivious of the damage I was about to inflict and I just increased it by bringing in the server front pages and modifying them. I see little point belaboring other obvious errors, when it is better to look at the methods used to recover from my foolishness.
Recovery
Recovery began with moving the style sheet out of version control back into the local, server receiving directory along with a renaming:
:~/OST-1$ cp -a css/style-sheet.css ../Documents/Selected-Files/style-sheet-test8.css
The rest you have seen previously: adding a new file, removing a misidentified file and removing the front pages and reverting to earlier versions. It was also necessary to bring down a server copy of a file that needed to be introduced to the next version along with the week's news items. Let the final status suffice to show the final result:
:~/OST-1$ svn status ? OST-1 ? howto/articles/HowTo-VersionControl-IV.html A howto/articles/HowTo-VersionControl-III.html A pr/news/InfoWorld-2007-BossieAwards-II.html A pr/news/InfoWorld-2007-BossieAwards.html A pr/news/mozilla_penelope.html A pr/news/new_holonyx_var.html A pr/news/zamand_news.html ? ceo/images/central-Tunisia.jpg ? ceo/articles/EU-climate-III.html A floss/articles/Disecting_opensource.html M page-1/index.html M page-2/index-2.html
The home pages shown as modified were now the correct version. The absence of the style sheet should be expected, since it had been entered into production two weeks ago. The interesting things now happen with the commit.
Commit Latest Version
The entire process is run within the limited rights user's directory and is quite quick with no wastage attempting it as non-root user:
# svn commit -m "Second week September version, front pages and two articles" Adding floss/articles/Disecting_opensource.html Adding howto/articles/HowTo-VersionControl-III.html Sending page-1/index.html Sending page-2/index-2.html Adding pr/news/InfoWorld-2007-BossieAwards-II.html Adding pr/news/InfoWorld-2007-BossieAwards.html Adding pr/news/mozilla_penelope.html Adding pr/news/new_holonyx_var.html Adding pr/news/zamand_news.html Transmitting file data ......... Committed revision 4.
Notice how few files were affected. So too the pattern for the update and subsequent checkout of the new version into the regular user's working copy were just as short:
# svn update A howto/articles/HowTo-VersionControl-III.html A pr/news/InfoWorld-2007-BossieAwards-II.html A pr/news/InfoWorld-2007-BossieAwards.html A pr/news/mozilla_penelope.html A pr/news/new_holonyx_var.html A pr/news/zamand_news.html A floss/articles/Disecting_opensource.html U page-1/index.html U page-2/index-2.html Updated to revision 4.
:~/OST-1$ svn checkout file:///etc/subversion/repos/OST-1 A OST-1/howto/articles/HowTo-VersionControl-III.html A OST-1/pr/news/InfoWorld-2007-BossieAwards-II.html A OST-1/pr/news/InfoWorld-2007-BossieAwards.html A OST-1/pr/news/mozilla_penelope.html A OST-1/pr/news/new_holonyx_var.html A OST-1/pr/news/zamand_news.html A OST-1/floss/articles/Disecting_opensource.html U OST-1/page-1/index.html U OST-1/page-2/index-2.html Checked out revision 4.
The take away lesson is, despite the project as a whole changing revision number in unison, only those files having real changes or additions were affected. Therefore, only those files imposed any computation stress on our system.
There is little that can be added, the process with a modicum of care can become routine and secure, just try to avoid some of the errors I found.
Another in the Series
How To: Coding html and css files by hand. I simply found new ways to imperil the validity of the content of the source control system. I downloaded file copies from the server, but mistakenly modified them so that they became altered files that would have been included in the source repository upon the commit prematurely. I showed the methods I used to back out of this problem, since this time the altered files were not newly named they would have been included. Best advice, is keep your mind sharp and be aware of what you are doing.
Corrections, suggested extension or comments write: How-To-Guy. If the mailto does not work, use this: hcohen[-At-]bst-softwaredevs.com.
© Herschel Cohen, All Rights Reserved
Return to Home or Tools Page
____________________________________________________________________
* Originally published on the Open Source Today site September 25, 2007. Content may have been altered prior to being moved onto Web Site Developers.