Monday, March 14, 2005

Fun with Subversion

I'm in the process of getting the Digest ready for the move to subversion. I've got the base class that gets stuff from the repository done, now to tie the whole thing together. I'm still not quite clear how access to the older issues will happen, ie. do I keep a cvs repository available? In any case things are progressing.

Some questions and comments come to mind. How will the mirroring work? If the kde svn repository is in bdb format, does rsync work? I searched for subversion mirroring in vain. It looks like I'll need to have a local mirror to allow reasonable performance (more on that below).

Subversion has some neat features for viewing the repository without creating a local copy.

svn list https://svn.kde.org/home/kde/trunk/ 
give a directory listing. 

svn cat https://svn.kde.org/home/kde/trunk/kdeedu/khangman/ChangeLog 
gives you a copy of the file, and if you 

svn cat -r ### https://svn.kde.org/home/kde/trunk/kdeedu/khangman/ChangeLog 
with a revision number, you can get that version. So you could browse the repository 
without checking out. I use these commands to generate the digest. Oh, another neat 
feature is the log output in xml format.

One thing that I've found a bit annoying is to get a diff for the changes that make up a revision. If you use svn diff -r 300000 https://svn/repository/and/file.c, it gives you the difference between that revision and head (assuming you don't have a local copy). If you want the difference to the previous version, you (or I, as in had to code) need to figure out the previous revision, ie. previous:current. Since revision numbers are incremented with each change to the whole repository, I get the log for the file, get a list of revision numbers then get the desired number to get the diff. Maybe I'm doing this wrong, but I couldn't see any other way from the documentation. In other words, to get the diff for a revision, I need to get the log for that revision and grab the list of edited files, get the log for each file, figure out the previous revision for that file, get the diff, rinse repeat. Since the revisions may touch any number of files, creating a diff display requires at least three svn commands. Hence the need for a local mirror.

As I said, things are progressing.

There seems to be quite an audience for KDE related information. A dot link brought down a server. I checked the logs, and for the march 11 issue, there have been 9310 hits. That is using a rather unscientific 'grep -c newissue=mar112005 access_log'. The previous issue had 11232 hits. Who would have thought there would be that many people willing to read commit logs?


Comments:
It's actually much easier than that. You can ask Subversion for a diff on an entire tree (instead of just on individual files). So you can get a complete changeset for all files with a single command:

svn diff -r rev-1:rev https://svn/path/to/repo/root/

e.g. if you want to see all changes made in r3000, you would do something like:

svn diff -r 2999:3000 https://svn.kde.org/home/kde/

Or if you just want changes in trunk/:

svn diff -r 2999:3000 https://svn.kde.org/home/kde/trunk/

This also works fine for getting diffs for individual files; you don't have to look at the log and specify the last rev in which the file was changed; you can just go (rev - 1):rev.

For example, say you're looking at foo.c, which was changed in r5, and again in r10:

svn di -r 9:10 https://blah/blah/foo.c

will give you the changes made to foo.c in r10, even though foo.c wasn't touched at all in r9.
 
Maybe you should take a look at svk. It supports, among other things, mirroring.
 
Thanks des. I thought there must be an easy way.

Derek
 
Using bdb is not the best idea out there. I believe using fsfs offers much better archiving / mirroring convenience.

Take for example in compatable versions of db4 engine. I had to run with all sorts of issues when I was mirroring a repository across two versions of linux.

fsfs on the other hand, saves each revision (or changeset) into a separate file. This is easier to administer and to rsync. The mirroring site would only have to provide svnserv / or mod dav svn (apache 2.0) as opposed to offering a compatable db4 as well.

Actually this allowed me to do low level tweaks such as manipulating revisions (all fsfs rev files are text-based and human-readable).

Regards,
Kefah T. Issa,
freesoft TECHNOLOGIES.
www.freesoft.jo
 
svk is the option to use when mirrors are being contributed to; is this your case?

If its not, then rsync is my preference.
 
Very informative blog. Please check out my linux operating system blog.
 
Informative blog. Check out my icon kde blog.
 
Hello, your blog is informative. I have a linux server related website, please visit and hope that it is helpful to you
 
Post a Comment

Subscribe to Post Comments [Atom]



Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]