Eirik Bjørsnøs wrote:
> Hi,
>
> I recently mentioned[1] some issues I was facing adding merge tracking
> features to my version control history search tool [2].
>
> Having spent the last few days doing some actual work on this feature,
> I have run into some issues with the Subversion log APIs/protocols.
>
> Using the current API there's no way for me to specify the exact kind
> and amount of information I want from svn log.
>
> Specifically, here are the issues I'm facing:
>
> A) Can't specify depth of include-merged-revisions (-g)
>
> If a merged revision also has a merged revision it will be included in
> the log. (And that revision can again be a merge of a merge of a merge
> many levels down..) Since I look at the repository log as a whole, it
> doesn't make sense to log merged revisions more than one level deep.
> Any information about "nested" merges will have appeared earlier in
> the log.
>
> The following thread discusses a --depth parameter, but I can't seem
> to find it leading to any conclusion:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=661083
>
> Proposal: Add a --depth switch to svn log (and the protocols, simple
> client filtering won't be very useful).
>
> B) Can't limit information returned specifically about merged revisions.
>
> The -v option currently applies to merged revisions as well as the
> "actual" revisions. I need full information about the actual
> revisions, but for merged revisions I only need the number of the
> revision. Everything else I already have cached.
>
> For my specific use case a special "--just-revision-for-merged" would
> be ok. However, for consistency it's probably better to add versions
> of --verbose, --with-all-revprops and --with-revprop that apply
> specifically to merged revisions.
>
> Proposal: Add merge-specific versions of --verbose,
> --with-all-revprops and --with-revprop.
I wonder if the following idea would help in these cases. In the repository
layer, instead of returning the complete depth of the merged revisions, just
return the ranges (if requested), this would allow the client contacting the
repo to make repeated requests if "deep" merge information was desired, or
selectively request additional information about merged revisions of interest.
The above change has been discussed before, but I don't think anybody has made
any progress on it. The idea is pretty straightforward, but the implementation
will be by no means trivial. It would require a bit of on-list discussion to
hammer out the semantics of the APIs.
Eirik, does this sounds like something you can look into?
-Hyrum
Received on 2008-09-06 02:46:12 CEST