[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 10:07:15 CET

> > Do you have unit tests for it? That would be important for testing
> > any new implementation.
> I wish we had unit tests for it. That would be important for testing
> any new implementation.

Hmmm. How many unit tests are there for SVN in general?
> Yes. I think it would be reasonable to simply use an array
> implementation with good slice operations, though it would be
> nice to use a representation that handled adjacent lines from the
> same revision in a space-efficient manner. Even a naive dynarray
> might outperform the current approach.

Yes. Less work allocating blame fragments etc. We need that profile...

> > If I can get you the raw information (with file content omitted) would
> > that do?
> Yes, the raw information would be fine.

It will have to wait until our trial SVN server is back up again. We're
having problems running cvs2svn on Win32. It hangs...

> > One other comment: when doing blame for multiple files the output
> > doesn't include any information about the file that was being
> > accessed.
> >
> We need to decide whether that's a bug or an API change before we
> fix it. My vote is for "bug".

Sounds good :-)

Also, is it OK to pass wildcards to svn blame? I tried using * but got an
error message back from the server, which appeared to be complaining about
a folder with just a single file in it, which had no revisions (just the
initial checkin). I wasn't sure if that was a problem in what I was doing,
or with our SVN repository, or with SVN itself.

Obviously if you use wildcards then the filename information in the output
is more important.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 13 10:08:52 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.