Web Site
Developers
Version Control as a Backup Tool
First Use
It was not intentional, but my later work on OpenSourceToday evolved where I copied up files directly from the version control onto the server. Moreover, I started making quick fixes directly on the version control copy (local) and then loading it onto the server. That cycle, my loading, my testing and my correcting code continued until I had acceptable functionality.
Despite my having a poor fit between the site and the version control directory structure, I abandoned old habits. I believe that implies a natural existing advantage, hence, I found myself relying increasingly upon the version control copy.
Old Habits
There are several, good reasons for my not opting at the start to synchronize my source to the site files. I explained I added version control late in of that site's development cycle. Furthermore, I focused on the the server and the site, where I routinely worked using a remote terminal. This was not an irrational choice, since I administered most of the server and was webmaster of several sites. Therefore, initially this determined my choice of tools.
I do not find the command line intimidating and am comfortable using a remote console for site access. Since the site (OpenSourceToday.org) was my focus it made sense to work primarily on the server to develop my site building skills. Therefore, it was natural to employ the tools readily at hand for multiple tasks on a text based server.
Despite these factors, I moved away from what at first sight should have been my natural preference. Hence, there must be a strong advantage gained when I rely upon the local development tools. That is, even when I had administrative rights and access I drifted away to a more efficient mode of operation.
New Situation
I no longer have the degree of control I had previously. On shared access host everything seems [1.] much more restrictive and easy fixes available to the webmaster and the server administrator are options no longer available. Moreover, at the onset, I had a source control project defined, hence, working locally and off a working source control copy made intuitive sense. Thus, I tried to keep the structures of the version control and the site as sychronistically matched as possible.
Standard Operating Mode
Now I begin my work by opening the version control system (Subversion). If I am creating a new page, I open the editor citing a file in an appropriate directory within the subdirectory articles. In the case of a new article the file is created [2.] and appears as a blank page. When I reach the point that I think I may have an acceptable page I call up ftp application (gftp) and connect to my site. My experience has been that on the left side I see my version control directory on startup. Upon connecting to the server, I move to my site then to the matching directory I wish to load.
Here is a rough picture of what I work with:
Figure 1. Graphic FTP Tool (gftp) for Web Site Synchronized Updates
on the left you are looking at the Subversion's directory of the working copy and on the right the web site directory. Once a new or revised file is loaded successfully, I test it in another session where the web page source is adjacent to the browser on a second monitor [3.]. I find the first version is rarely acceptable with flaws readily apparent. Therefore, my standard process is to revise the working copy, save the changes into the source control and then recopy the revised copy onto the server.
I advise being cautious, i.e. be certain it is the revised file that is copied onto the server. That requires refreshing the file listing in the version control. I suggest being aware of the approximate size of the net change in character count, hence, if you made a net change by the over write warning shows no change or differing markedly in file size you should examine the date time stamp for the file prior to copying over the file. It could be as simple as not having saved your revisions. Unfortunately, I speak from experience, since this and other errors have happened bitten me.
Once I reached this stage, unless rushed, I would not have a link from the site's surface to the article's location. That allows me to take a fresh look to catch missed problems. Eventually the content has to be exposed, at that point I add it to the appropriate menu. Nonetheless, even if you have set the meta tag to noindex and nofollow do not be shocked seeing a bot has found your site upon viewing your logs. If your new pages are not hidden, your content will be soon visible to all.
Version Control is not the Perfect Backup
I must warn you of several potential pitfalls. A source/version control system is designed to track code changes between committing of latest project revisions. If you are as lax as I this might become a problem. Your intermediate changes between commits are irretrievable lost. In addition, I must warn you, if you do not keep your source synchronized consistently a failure could be a disaster. Therefore, if you think that is likely, I suggest pushing yourself to do backup copies of your site on a fixed schedule, or upon every change.
There is one additional problem I should warn you, it will clearer by seeing the copied code below [4.]:
:~/OST-1$ svn status ceo/articles/ ? ceo/articles/Small-to-Micro-GasTurbines-II.html ? ceo/articles/EU-climate-II.html ? ceo/articles/Small-to-Micro-GasTurbines-V.html ? ceo/articles/Electro-Pneumatic-Braking.html ... ... ? ceo/articles/ceo-start-page.html A ceo/articles A ceo/articles/EU-climate-I.html
The question marks mean that the version control system does not know if those files are part of the project. Hence, do not assume that new files are added automatically. If you want it added, run the command. For me this is a positive feature, because not every web page I write will end up on my own site. Moreover, I wish to have a test version on the site, but invisible from casual visitors. Therefore, it serves my purposes.
Finally, I have one additional feature that extends my project beyond a nearly perfectly matched copy. I also have areas where I store raw research results and graphics that were not used. These, however, may be subdivided in separate directories to more closely match a particular article. Thus, making retrieval less of a problem should I wish to remind myself of the basis of my assertions.
Version Control Helps, It Alone is not the Answer
Version or Source Control is not a perfect backup tool, that is not its purpose. Moreover, I would suggest that if it is likely that you will not consistently synchronize the control to the site files that you skip it entirely. At least that way you will not fool yourself into believing your site is protected.
If you follow my suggestion, view source control as one naturally occurring repository that contains much of the details of a project. It will, however, be useless if it too is not distributed to other locations should you have a major failure. At best, source control can be a strong aid, if it matches the way you create and maintain a site. Nonetheless, if your mode of thought differs, avoid it.
In conclusion, I think using a version control copy could be a quick method to recover a trashed site. Nonetheless, if you are careless, it could be a poor choice.
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
____________________________________________________________________
1. "[S]eems" is the operative word, while all changes seem
tied to their their GUI, I learned in certain instances I
could use the command line. Return
2. Unless you submit a save command in your browser, the file
does not exist yet in the directory. Return
3. Contains photos of my dual monitor setup in figure 2.
Return
4. This output was copied from the third article in this
series, however, there it demonstrated a different point.
Return