The folks on the ProFox mailing list liked this one: “Source code control is a necessity when the number of programmers exceeds _zero_.”
Microsoft’s proprietary source code control system, and subject of the book “Essential SourceSafe” by Ted Roche.
Picking up an example presented in 1998 for using COM Automation on SourceSafe from Visual FoxPro, I created the same example in Python with just as little code. Using Mark Hammond's Win32All to supply the Win32 and COM support, the following code will list all the files in a particular SourceSafe project and their version numbers.
import win32com.client SSafe=win32com.client.Dispatch("SourceSafe") SSafe.Open("c:\Projects\VSSPath\srcsafe.ini","troche","secret") Root=SSafe.VSSItem("$/MyClient/MyProject") VSSItems=Root.Items print VSSItems.Count for loNode in VSSItems: print loNode.Name, loNode.VersionNumber
OSNews reports Subversion 1.4.0 Released. “This is a feature release of Subversion, featuring BDB 4.4 and repository auto-recovery support, a new tool for synchronizing repositories (svnsync), major speed enhancements in the versioned filesystem and the working copy, and of course the usual host of bugfixes and minor enhancements. Additionally, check this article on how to Set up Subversion and websvn on Debian.”
Good timing! I've been using subversion for the past year on a web development project with another (remote) developer, and have enjoyed the power and flexibility of the tool, as well as some of the cool add-ons, clients and scriptability.
Now, it's time to consider moving existing projects out of Visual SourceSafe and into subversion. The folks at Pumacode offer an vss2svn tool that runs as a native Windows executable, written in Perl and C, with the source available under an open license. Pumacode tried an interesting tactic to convert the VSS repositories: rather than interogate the VSS binary to retrieve files, it reads the repository files directly and interprets the results from there. There are some advantages where older versions might be corrupted, or to retrieve files flagged as deleted, which they say VSS will not allow.
On a 2 Ghz Pentium-M with a gig of RAM, it took about 2 hours to process my current VSS repository, which consists of forty thousand files and around 1.4 Gb of disk space. (The authors of vss2svn caution that it's better to convert the entire repository than to risk further corruption by pruning it first; leave that task to subversion post conversion.) This generated a dump file of 850+ Mb. Transferring that to the Linux box with a new repository took a few minutes, and loading the data about 20 minutes. Using RapidSVN from the Windows box, I was able to browse the subversion repository and confirm that files and folders and log history comments look about right. I'll confirm by checking out projects of interest and diff'ing them against the current development copies.
I had anticipated a different tack, using COM Automation to drive VSS, as I described in Essential SourceSafe. As a learning project, I had proposed using Python to browse the repository via COM Automation and use the excellent Python-svn bindings to migrate portions of a VSS repository to subversion. I still plan to try that, and to compare-and-contrast the results between the two techniques, while I learn a little more Python.
Robert McMillan of reports . “With Microsoft Corp.'s Office suite , researchers at the French Ministry of Defense say users of the OpenOffice.org software may be at even greater risk from computer viruses… “The general security of OpenOffice is insufficient,” the researchers wrote in a paper entitled “In-depth analysis of the viral threats with OpenOffice.org documents.” … “This suite is up to now still vulnerable to many potential malware attacks,” they wrote.”
Despite the negative tone of the beginning of this article, it's more good news for OO.o than bad. First, the one major flaw that was found has been patched – yeah, Open Source! – and you'll want to ensure you're running the latest OpenOffice.org. The second positive spin of the article is the tone: governments and companies are seriously evaluating OpenOffice.org as a replacement for their current office products. I wonder if this change in the tone has to do with the acceptance of the Office Document Format as a recognized international standard.
In the original post, I showed a simple Visual FoxPro program to generate a week’s worth of activity history from Visual SourceSafe. Andrew MacNeill observed that it would not work for him, as he was supporting more than one database. Here’s one solution: change the original program from shelling out with a single command. Instead, generate a batch file, and then execute it. Here’s a sample:
SET TEXTMERGE TO VSSHIST.BAT SET TEXTMERGE ON NOSHOW \ SET SSDIR=C:\MY DOCUMENTS\SOURCESAFE \ SET VSSEXEDIR=C:\PROGRAM FILES\VSS\WIN32 \ %VSSEXEDIR%\ss history $/ -R -vd <<DTOC(DATE())>>~<<DTOC(DATE()-7)>> -B -O@History.txt SET TEXTMERGE OFF SET TEXTMERGE TO !VSSHIST.BAT SET SSDIR= SET VSSExeDir=
[UPDATED]: My blogging software made mincemeat out of the slashes, greater-than and less-than signs. Copy with care, and proof your result.
The SSDIR environment variable is recognized the the SS.EXE SourceSafe command-line executable: if set, it points to the SRCSAFE.INI file and the location of the data files SourceSafe is to operate on. The second environment variable, VSSExeDir is one I use to simplify the batch file, but putting the absolute path to the SourceSafe executables in one place, you can refer to it within the file, and only need to change it in one place should you change paths. Think #DEFINE in other languages.
Andrew follows up on my 30 June post on Ted Roche – Building SourceSafe Activity Reports using VFP. “Ted hasn’t updated this yet but his code for generating weekly activity reports from Visual SourceSafe is going to help me out plenty… We had to make some adjustments for databases that are not stored in the root directory (mine are stored in another folder).”
Well, actually, the problem is that the code as written in the original post assumed that the SourceSafe client on the machine running the report was set up to point to the repository of SourceSafe data by default – an obscure registry setting. If not, use the trick in Andrew’s post to set the SSDIR environment variable to point to the SourceSafe repository of interest. Also, it’s a very good idea to run this on the local machine with the SourceSafe repository, as network traffic can slow the performance by orders of magnitude. Andrew goes on to note:
“By the way, Ted’s work is licensed with Creative Commons Attribution Share-Alike License,… If you use it, great. If you fix it, pass the fixes along using the same license. A great approach for offering code. ” My thoughts exactly.
Building on the work covered in Essential SourceSafe, here’s some code that will generate two text files of the activity that your SourceSafe database has recorded in the past week. This can be a handy way to keep track with what’s going on in a busy project.
(Changing the text output into an RSS feed is an exercise left to the reader. Cool idea, eh?)
I used Visual FoxPro to generate the commands for SourceSafe, as I couldn’t figure out a way to generate a date less seven days in a DOS command shell. In my next post, you’ll see a slick way to generate the current date, but that didn’t help me here.
Save this program into a Visual FoxPro project, and optionally add a CONFIG.FPW with RESOURCE=OFF, SCREEN=OFF and build it into an EXE. Place the WeekHist.exe in the root of your SourceSafe install (or change the paths in the code below to match) and you can run the exe manually or set the .exe to run on a weekly scheduler using the OS’ scheduler tools.
*============================================================================== * Program.............: WEEKHIST.PRG * Purpose.............: Generate a weekly history file from SourceSafe * Author..............: Ted Roche * Copyright...........: 2000-2005 by Ted Roche, licensed under the Creative * ....................: Commons Attribution Share-Alike License, * ....................: http://creativecommons.org/licenses/by-sa/1.0/ * ....................: Please fix and pass along - Ted * Last revision.......: 2005-June-30 * Parameters..........: None * Returns.............: Nothing, outputs History.txt, .lst or .err * Environment in......: Must run in root of VSS install, ASSuMEs that the * ....................: data directory and win32 directories are below * Environment out.....: History.txt is brief, History.Lst is verbose *============================================================================== * Format is: * win32\ss history $/ -R -vd07/02/05~06/26/05 -O@History.lst * Try...Catch would be nice, but this supports any VFP runtimes #DEFINE CRLF CHR(13)+CHR(10) ON ERROR do errhand with ERROR(), MESSAGE(), MESSAGE(1), LINENO() lcCommand = "win32\ss history $/ -R -vd" + ; DTOC(DATE()) + "~" + ; DTOC(DATE()-7) + ; " -B -O@History.txt" RUN &lcCommand lcCommand = "win32\ss history $/ -R -vd" + ; DTOC(DATE()) + "~" + ; DTOC(DATE()-7) + ; " -O@History.lst" RUN &lcCommand RETURN PROCEDURE errhand(tnError, tcMessage, tcMessage1, tnLineno) STRTOFILE(TTOC(DATETIME()) + " Error " + TRANSFORM(tnError) + CRLF + ; " Message " + tcMessage + CRLF + ; " Message1 " + tcMessage1 + CRLF + ; " Line " + TRANSFORM(tnLineNo)+ CRLF , "History.err", .t.) ENDPROC && errhand