kasia in a nutshell

A few months ago, I posted an entry asking about bug tracking tools. A few people recommended JIRA and after evalutation, showing it off to our team and a happy gleam at the price tag we purchased an enterprise license and have been using it ever since. It's really a great tool and likely the best bug tracking one I've ever used.

Months went by.. project has grown and today was the day to move our bug tracking to a newer, faster non-ppc based server. Since JIRA is Java-based, the move is really nothing more than tar and un-tar.. what could be easier? We're just hopping linux boxes here!

As with any project, a test run is required, so of course about a week ago (September 1st to be exact) a tar of JIRA was created, un-tar'ed on the new server and tested to make sure all runs.. And it did! Like a charm.. piece of cake.

Today.. the moving day. All I had to do was create a fresh, new tar and un-tar it (yet again) on the new server.. what could be easier!

tar -xzvf jira.tgz jira-directory

Yah.. I typed "x" instead of "c" and of course.. there was already the previously tar'ed file (from September 1st) there and since I was pulled into a meeting as soon as I hit "enter" I didn't even notice this.. that is.. until I brought up JIRA on the new server and saw all the missing data.

Ahh!! Blew away a week's worth of work! What's worse.. not even my own work but that of other people!

This is where the love of JIRA comes in.. the default configuration backs up its data every 12 hours into xml files.. and since the file has the date in the name, the new backup files were not over-written when un-tar'ing the old files over the location..

Thank you.. oh blessed JIRA developers you saved my back-up-deficient ass!
(Yah, we'll be backing up the new server regularly).

Posted by kasia at 01:45 PM | Permalink | Comments (3)

Being an active contributor to technical forums I am often faced with surprisingly simple questions about basic programming environments from computer science students. Students are often lazy and why should it surprise me that so many don't bother to learn the basics, right? Maybe, but too often it is ones who are otherwise bright and not at all lazy. So what is the true problem?

Thinking back to my own basic programming classes I think I can see the problem clearly. I cannot think of one professor that explained the programming environment in class. The books tend to skip over those parts as well.

What is the number one problem students have with their Java projects?

Classpath.

Something as simple and basic as that, it's just not explained in class. Is it too simple and ought to be self-explanatory? Perhaps, but I wouldn't expect a first year CS major to grasp the concept of classpaths without at least a basic introduction, why are CS professors expecting it? Sit a student in front of a tool like eclipse and I guarantee their eyes will glaze over and a simple concept like a compiler will not occur to them on their own.. command line? Forget it.

With the development environments getting more and more complex each year and the command line being something of the past (unless you're a unix geek like me) I think CS programs should look into providing classes in basics of development environments. Using tools like source control, IDEs, etc. It would help the students understand programming better and give them a better start in the workplace.

Posted by kasia at 09:16 AM | Permalink | Comments (7)

Because of the emacs dumper which makes all sorts of assumptions it really shouldn't, compiling emacs on Fedora generates a core dump when dumping.. error looks sort of like..

Dumping under names emacs and emacs-21.3.1
make[1]: *** [emacs] Segmentation fault (core dumped)

There's a very easy way to fix this:

setarch i386

and emacs will build just fine.

Posted by kasia at 02:59 PM | Permalink | Comments (1)

Running "svn update" is really simple and speedy, but I like having a nightly cronjob updating my local copy of the code, so I wrote a script that does just that and sends me a small, quick summary of what it did, paying special attention to conflicts.

I really don't care what files have changed, were added, etc, but I do care which files have merge conflicts.. so that's what this script does.. output looks something like:

Tue Sep 21 15:40:50 2004 Updated /home/ktrapszo/test

1 Conflict Detected!

Conflicted files:
/home/ktrapszo/test/test.java

2 files added
13 files updated
0 files deleted
0 files merged

Finished update in 13 seconds

That's really all I care to see, if I want specific updates on specific files I can always check the daily changelog email.

So for those who work like me and like an automated update that only sends a small summary of important info, the script is here.

Posted by kasia at 04:19 PM | Permalink | Comments (1) | TrackBacks (1)

HP Unix (or as I like to call it h-pox and a pox it is) is not a popular platform and thanks to my recent exposure to it I completely understand why. The non-ansi C compiler it comes with is a winner as is the fact that its getpass() library only accepts 8 characters (what is this, the 80s?) as I just learned. The hard way.

So if you want to compile the Subversion client on this OS, it will only work with short passwords.. unless before configuring you let APR know not to use its own getpass() instead of the system's.

The way to do that?

setenv ac_cv_func_getpass no

This tip brought to you by Joe Orton of the Subversion user's list. Thanks!

Posted by kasia at 09:32 AM | Permalink | Comments (5)

Some subversion benchmarks I've done.. mod_ntlm is an apache module and can be found here, AuthenNTLM is a perl apache module that does the same thing and can be found here.

Benchmarks were done using 1892 plain text source files. Total size of data: 25MB in svn: 66MB. Each commit was done to a freshly created repository and then a subsequent checkout of the same files to a fresh work area.
Connection over a partial T1 shared by about 20 people during regular business hours.

The strangest result seems to be mod_ntlm + ssl being faster than mod_ntlm alone.. I ran that benchmark twice during two different times of the day and the result was the same. Odd.

Note: These would obviously be affected by (a) traffic on the network and (b) how busy the svn server was at the time of the benchmark, but more or less it should show which access methods are faster than others and what is the price for more secure access.

Posted by kasia at 05:37 PM | Permalink | Comments (0)

So far one on the list that I discovered just today. When you request Subversion provides you with a diff between current version and previous revision (svn diff $file) it looks at the timestamp of the current file and the version in repository. Given the timestamps are identical, diff always returns false.. This is a problem.

I discovered this when running test conversions from our ClearCase repository.. turns out that sometimes my script is just too fast and a version of a file may have the same timestamp as the previous revision which means subversion merrily ignores the change and doesn't commit it. Ironically, this would be less of a problem on windows since windows stores milliseconds not just seconds as unix.. but that's a whole other issue. Of course this is pretty easy to fix in my script.. just touch the file with its original revision date and subversion is happy to acknowledge the changes.. but I see this as a weak point in what I thought was a pretty well thought out scm tool.

The reasoning behind it is of course performance.. it's a lot faster to determine if a file has changed if you do not have to actually compare two files.. and size isn't the most reliable indicator. Well turns out.. timestamp isn't necessarily reliable either. Now if you put the two together.. size & timestamp in a hash you have a much higher chance of being correct when making the "is the file changed" assumption. Which is what I suggested on the Subversion users list and, as everything else in life, it just isn't quite so simple -- it appears the current implementation provides no simple access to the size information of the in-repository-revision.

Given that my original suggestion isn't something easily accomplished, I hope my second suggestion of allowed the user to override this default behavior (of course, performance will suffer but reliability will improve for scripted commits) will be implemented.

After about a month of pretty heavy usage and testing of subversion this is so far my biggest issue -- one not likely to be encountered in day-to-day usage. Not bad at all, my CVS list is a lot longer. Of course.. I haven't really started on hooks and heavy scripting yet..

Posted by kasia at 06:48 PM | Permalink | Comments (11)

1. Add it to services
   

   In /etc/services:
   svnserve 3690/tcp # Subversion svnserve
   svnserve 3690/udp # Subversion svnserve

2. Create the xinetd configuration file for svnserve
   

   In /etx/xinetd.d/svnserve:
   

   # default: on
   # Subversion server
   
   service svnserve
   {
           socket_type     = stream
           protocol        = tcp
           user            = svnadmin
           wait            = no
           disable         = no
           server          = /usr/local/bin/svnserve
           server_args     = -i
           port            = 3690
   }

   Of course, adjust the above for port, file location, user, etc.

3. Restart xinetd service
   

   kill -SIGUSR2 `cat /var/run/xinetd.pid`

4. Verify svnserve is listening
   

   # netstat -anp | grep LISTEN | grep 3690
   tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 3303/xinetd

   
   
   - or -
   
   

   # telnet localhost 3690
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
   

Posted by kasia at 02:45 PM | Permalink | Comments (3)