On Fri, 2008-08-22 at 13:19 +0200, Eirik Bjørsnøs wrote:
> Hi guys,
>
> I'm currently working on making my version control history search
> tool[1] merge tracking aware.
Heh! I hadn't seen that before. Looks useful.
> Using "svn log -g" (or actually "include-merged-revisions" in the DAV
> log-report) I'm able to get the merged revisions. So far so good.
> However, the log will include not only pointers (the revision numbers)
> to the merged revisions but the full information including author,
> date, log message and changed paths.
Do you know that the "--quiet" switch suppresses the log message? 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.
> This is undoubtedly a good thing if you're looking at single
> revisions, but I'm looking at the entire log history so I have a
> couple of concerns:
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). In such a case, I
would expect to see little if any repetition because any particular
change is normally only merged into the branch once. However, a quick
experiment on Subversion's trunk shows that the output does indeed
contain repetitions. I don't yet know why. Maybe a bug. I've alerted the
other developers to it.
I'm not surprised you get too much info if you run it against the whole
repos at once!
> 1) If the commit history has many merges and/or big merges a lot of
> redundant log information is put on the wire. The information for a
> commit will be logged once for the commit itself and then once more
> for each merge of the revision.
>
> 2) Depending on the implementation in the Subversion server I would
> imagine that getting all the revision information for merged revisions
> put some extra load on the server.
>
> Given that I only need the revision numbers for merged revisions I
> have the following questions:
>
> a) Is there a general interest in adding a switch that will make svn
> log only return revision numbers for merged revisions? Or is this
> somewhat of a corner case that normal users will never run into?
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.
a2) An API option and library implementation for suppressing all the
rest of the info from the client-server communication.
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).
At what level are you interfacing with the Subversion libraries? JavaHL?
> b) Would such a change require a lot of changes to the Subversion code
> base? Would these changes be risky?
The UI change would be quite easy but quite likely not much wanted. The
library change sounds like a very good idea but I don't know if that's
really the case nor how much is involved in doing it.
> c) Are there good reasons not to add such a swith?
>
> I'm a Java dork myself but it would be fun to at leat try and
> implement something like this if someone with a clue could give me
> some hints on where to start.
>
> Looking forward to hearing what you guys think.
>
> Thanks,
> Eirik.
>
> [1] http://svnsearch.org/svnsearch/repos/SVN/search
- Julian
---------------------------------------------------------------------
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-22 16:33:55 CEST