On Fri, Aug 22, 2008 at 10:33 AM, Julian Foad
> 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 merge tracking aware.
> Heh! I hadn't seen that before. Looks useful.
Same here. Very interesting looking tool. Is it open source?
>> 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?
We've discussed some general API improvements in the past.
1) It would be desirable if a "normal" svn log included a boolean that
indicated if a given revision was a merge. That could then allow a
caller to do a follow-up call to get the details for that revision.
2) It would be nice to have some kind of control over the depth of
recursion. I think this could be a simple as a boolean that either
goes only 1-level deep or infinite. I think you are going to
typically want one or the other.
These changes would be useful to GUI tools and also tools that have
their own cache. They'd also let these tools not hit the repos so
hard and generally provide better performance.
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:47:31 CEST