Julian,
On Fri, Aug 22, 2008 at 4:33 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>> I'm currently working on making my version control history search
>> tool[1] merge tracking aware.
> Do you know that the "--quiet" switch suppresses the log message?
I didn't, but it will also suppress the log message of all revisions,
not just the merged ones. So I'm afraid that won't help me much..
> I believe it suppresses it from the client-server communication as well as
> from the output of "svn log". That might not be enough of a saving for
> you, but the way it does it might give you a clue how to implement an
> option for suppressing the rest of the data.
Thanks, that's a good point, I can use that as a starting point
looking into this.
> The expected use cases for "svn log -g" are, I assume, that you are
> asking for the log of one branch (or a subset of it).
Not really. What I'm interested in is to follow the global history of
a project. You may think of it as doing a "tail -f " on the repository
history. When fetching the log for the initial round I do what would
be "svn log --xml -v -r1:HEAD" on the command line. Then I remember
what HEAD was last time I asked and use that next time I check for new
changes: "svn log --xml -v -r<LASTHEAD>:HEAD.
Given that any merged revision will always have a lower revision
number (a merged revision precedes a merge) I already have the data
about any merged revisions in my own cache. So the only information
interesting to me is a) that a revision was merged and b) in what
revision it was merged.
> Split the request up into two parts:
>
> a1) A user-interface option for the client "svn log" to show only
> revision numbers for the merged revisions.
That might be useful for humans using the SVN client. I'm parsing the
XML myself from the network myself so it won't help me much.
> a2) An API option and library implementation for suppressing all the
> rest of the info from the client-server communication.
That's exactly what I'm looking for. A switch that tells the server to
just put the numbers on the wire. It doesn't even have to look up the
extra revision info, so this might also speed things up server side.
> These two are independent: apart from efficiency (OK, I know that is
> your motivating issue), either one can be implemented without the other
> one. I expect you only need (a2).
Yes.
> At what level are you interfacing with the Subversion libraries? JavaHL?
Until now I've been using the latest release of the JavaSVN before the
changed to a viral license. For the merge tracking work I'm replacing
that with my own Java library implementing just the subset of features
I need. (svn log plus svn cat basically).
Thanks,
Eirik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-25 11:43:57 CEST