[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Getting raw blame information

From: Hugh Gibson <hgibson_at_cix.co.uk>
Date: 2005-01-13 13:25:15 CET

> > Hmmm. How many unit tests are there for SVN in general?
> >
>
> Lots. Really. SVN has a great unit test framework.

That's reassuring.

> But only two tests have been written for blame, and neither of those
> address the blame calculation directly.

OK.

> Run "make check" if you've got a lot of time on your hands. You can
> look in subversion/tests/clients/cmdline/blame_tests.py for what we've
> got in the way of blame testing.

Time is what I don't have a lot of.
 
> The right thing to do is probably to generalize the blame calculation
> routines and move them to libsvn_subr (or perhaps libsvn_diff), and
> add real unit tests to subversion/tests/libsvn_subr. This would
> lower the barrier to moving the blame calculation to the server side,
> too.

If it was on the server it wouldn't be limited by the network, so the
algorithm would be more important. However, I'm not going to be able to
afford the time to get into it all. I'll think about the algorithm some
more but the learning curve for SVN development would be too much when
we're working hard with a small team to get a new product developed.
 
> The wildcards are expanded by the shell on unixy systems, and by magical
> linker tricks on Windows. That is to say, none of Subversion's code
> handles command-line wildcards directly. That means that it's always
> okay to pass wildcards to Subversion.
>
> Is it possible that the wildcard expanded to a directory name, and that
> blame doesn't produce a nice looking message when run on a directory?

Yes, it's more than likely that this was the first directory name. I was
hoping that the command would be run recursively (like CVS annotate, which
works on all the files in the repository). I suppose I should just do it
one by one.

Hugh

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 13 13:27:07 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.