A few days ago I asked on the BlogCFC blog about a way to display a report from Subversion. I knew how to get a report of the latest updates for one file, but not for a project as a whole. A few people recommended Trac, but being the kind of guy I am, I wanted to build something myself.
Scott P (who has contributed some good changes to BlogCFC) told me what the SVN command was:
svn log -v svn://199.231.128.19:8000/blogcfc5 --limit 10
This command will give you a nice report of the last ten changes to the subversion repository. I was about to hook this up to CFEXECUTE and start writing a string parser when I had the brilliant idea of actually checking the documentation. Turns out if you add --xml to the command, you actually get the report back in XML:
svn log -v svn://199.231.128.19:8000/blogcfc5 --limit 10 --xml
No string parsing necessary! So I quickly whipped up some code (included below) and added the report to BlogCFC. You can find the SVN info here:
http://www.blogcfc.com/blogcfcsvn.cfm
Nice design, eh? Hard to believe I'm just a developer. The code is a work in progress, and not encapsulated into a CFC, but for those who want to add this to your site, I've included it below. Some notes:
- I'm not parsing the dates yet. It's UTC, so I just need to add the offset which I can get from getTimeZoneInfo().
- You could make the files linkable if you wanted, but you always need to be extra-super-anal-etc when writing code that will dump another file live on the web. In fact, I'd probably just not recommend doing this unless the entire application is very secure.
- SVN also reports what happened to the file. So for example, I think it uses M to signify that the file was modified. I bet it uses A for Add and D for Delete, but I haven't confirmed this. I'd like to update my code to not just show the files but what the change was.
- And as I said above, this should be rewritten into a little UDF or CFC.
<!--- path to svn --->
<cfset svnPath = "svn">
<!--- whats the url? --->
<cfset svnURL = "svn://199.231.128.19:8000">
<!--- how many entries --->
<cfset top = 10>
<!--- args --->
<cfset args = "log -v #svnURL# --limit #top# --xml">
<!--- run it --->
<cfexecute name="#svnPath#" arguments="#args#" variable="result" timeout="30" />
<!--- parse to xml --->
<cfset data = xmlparse(result)>
<!--- get entries --->
<cfset entries = xmlSearch(data, "//logentry")>
<cfset logEntries = arrayNew(1)>
<cfloop index="x" from="1" to="#arrayLen(entries)#">
<cfset entry = entries[x]>
<cfset logEntry = structNew()>
<cfset logEntry.revision = entry.xmlAttributes.revision>
<cfset logEntry.files = arrayNew(1)>
<cfloop index="y" from="1" to="#arrayLen(entry.xmlChildren)#">
<cfset xmlChild = entry.xmlChildren[y]>
<cfswitch expression="#xmlChild.xmlName#">
<cfcase value="author,msg,date">
<cfset logEntry[xmlChild.xmlName] = xmlChild.xmlText>
</cfcase>
<cfcase value="paths">
<cfloop index="z" from="1" to="#arrayLen(xmlChild.xmlChildren)#">
<cfset thisFile = xmlChild.xmlChildren[z].xmlText>
<cfset arrayAppend(logEntry.files, thisFile)>
</cfloop>
</cfcase>
</cfswitch>
</cfloop>
<cfset arrayAppend(logEntries, logEntry)>
</cfloop>
<cfdump var="#logEntries#">
Archived Comments
For a possibly more integrated solution you could look at using the JavaSVN libraries from ColdFusion to get access to the real data. Drawbacks there, you would probably have to have cf on the same server as the subversion repo. But it could be easier than having to get cfexecute access to a script to run the process.
Just an idea.
Good points. I'd also suggest simple caching. Anything that both shells out, AND does network stuff should be cached.
Do not underestimate the power of the Trac side.
Trac is the best use of Wiki technology I have ever seen.
Ok Ray, that is just damm cool!
We will be adding that to our codebase today!
If you want ultimate insight into an SVN or CVS repo, I recommend FishEye. In action:
http://fisheye.codehaus.org/
Ray,
Do you do most of your development on your local machine? I was just curious, as I found subversion very cumbersome (compared to saving files right on a development machine)
Remembering to check files in or out, setting up a directory to check files out into, remembering all the files I touched in order to save a revision, ugh!
Anyone have something like Eclipse's 'Local History' feature that works on a remote folder that everyone shares? That seems so much simpler to me. I know I am a single developer, and have never worked on a team, but I found Subversion horribly intrusive.
This is one of the coolest features "NEEDED" for CF. We need great version control to do good development. Good start on a worthy project! If there is something I can do to help move something along this line... heh, might even promote a fund raiser in our user group for your wish list. Very creative solution... and good job.
Hi Justice,
Try http://tortoisesvn.tigris.org/ it makes working with subversion a joy.
Doug
I like Tourtise also. But there are times when it would be great to be able to manage the SVN from within a CF application. Think of project management or even deployment being managed from within an application.
CF Project Manager Senario:
1. Archetect Application
2. Customer Signs off on Design Based on Archetecture
3. Generate Core Files and to be programmed files.
4. SVN Files
5. Programmer works on file until it is ready for project version (even if partial beta level.) and SVN stores it from project manager in CF. This is done along with a Unit Test which is generated and stored along with the SVN files in an automatic fashion. Unit Test Report and SVN from single interface.
6. Another programmer takes same file now to the next level... on his development machine from same project manager running on his development machine.
7. Once files are complete the files are set to a version level being the feature complete for a "release/beta?" version and deployed to test... or to live.
(P.S. A tool that works with version control, an IDE for comparison would be key to making this productive. But submissions would be done from a common interface that did Unit Test and then Stored the test along with the version. Connecting this all with project management software would also allow tracking of other things at the same time. This may not be how everyone would want to do it... but to me this would be a great move foward in multi-developer software solutions.)
P.S.
On senario where I would like to use this is to have a project know that certain core files are sourced in another SVN project. I could flag those files via CF (and a data store knowing which key files) to update the core files. To me that would be pretty cool. Then they could be stored in the actual project SVN for others to pull for development, testing and pushing to the live server.
Oh, managing what versions are in test and live would also be something I would store in my project. I would also use the project manager to connect my ticketing system to "version numbers" in SVN. It helps to know all the common issues when working on a feature request enhancement or a debugging issue.
Justice, you don't need to check the stuff out. Normally you get all the files from the repo. Then you can edit at will and check in when you want. To remember what you have modified, just use something like Tortoise. It will color code files you have modified. Easy as pie. :)
I can say though that the Eclipse versioning IS darn slick.
John,
Everything you've described is done today with version control, whether it be automatically running unit tests after a commit or linking commits to an issue tracker.
For instance, see this ticket from the ColdSpring project:
http://code.coldspringframe...
The commits that were made against it are hyperlinked to our FishEye instance. Trac does something similar, but personally I think JIRA + FishEye (+ Confluence for a wiki) is more flexible.
Hmm Lighthouse Pro... Canvas... and now Ray is using CF to manipulate SVN repos. How much longer until there is a contest or something in the works for a Trac-like CF app?
Weird - the file attributes (M,A,D,etc) don't seem to come across in the XML? If I just dump the result with no --xml flag they show up.
Jim
I know I saw it. Or I'm pretty sure I did.
Eh - nevermind - I had a typo :)