If you have concrete suggestions for improving or extending the core,
we'll welcome them --- on the dev@ list please.
Pablo Beltran wrote on Wed, Dec 22, 2010 at 14:26:13 +0100:
> That would be a more efficient way to a achieve it but as you say that might
> not work in all cases.
>
> In my opinion a feature like that is enough important to be provided by
> Subversion via cmd line / API, because that is the one of the bridges
> between Subversion and Change Management tools (like Jira and others) to
> build SCCM baselines.
>
> Compare two tags in Subversion -> get all involved revisions in that -> get
> issues related with those revisions -> get easily the changes (issues)
> involved between two product versions
>
> Now that is also possible to achieve but it requires a lot of previous extra
> computing on the Subversion side.
>
>
>
> On Wed, Dec 22, 2010 at 1:25 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
>
> > Pablo Beltran wrote on Tue, Dec 21, 2010 at 23:29:23 +0100:
> > > Maybe the point is efficiency.
> > >
> >
> > OK.
> >
> > > the *svn log -v* output for a revision range could be represented by a
> > > matrix with the revision numbers as rows and the changed paths as
> > columns.
> > >
> > > So, for each revision is easy inquire the revised paths. That is simple
> > > because all the results are retrieved from one execution.
> > >
> > > But, how does efficiently transpose the matrix? -> paths as rows and
> > > revisions as columns? and do it for the same set of values?
> > >
> >
> > In other words, how does one compute for a set of paths which revisions
> > touched each of the paths?
>
>
> yes!
>
>
> > > For example, when two *tags* are compared with TortoiseSVN the result is
> > a
> > > list of revised paths. But revisions are missing from that view. That is
> > > because TortoiseSVN dispalys the *svn diff -summarize* results. So, how
> > to
> > > display also the involved revisions for each path? The *svn info*
> > displays
> > > only the last revision and not all involved so you should execute the
> > *svn
> > > log* command for each revised path. And that is not efficient.
> > >
> >
> > You could use the #2 syntax of 'svn log':
> >
> > % $svn h log | head
> > log: Show the log messages for a set of revision(s) and/or path(s).
> > usage: 1. log [PATH][@REV]
> > 2. log URL[@REV] [PATH...]
> >
> > I'm not sure offhand at what layer the looping on paths is implemented,
> > though; but I hope it's done server-side.
> >
> > > The goal is adding the involved revisions on the compare directories view
> > of
> > > TortoiseSVN and do it in the most efficient way.
> > >
> >
> > Solving the problem for the most general case of comparing any two
> > directories is a hard problem.
> >
> > >
> >
> > HTH,
> >
> > Daniel
> >
> > > On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name
> > >wrote:
> > >
> > > > 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies)
> > > >
> > > > 'dig the logs' is "lookup the copyfrom revisions of the tags, and run
> > > > log on replay.c for that revision range". What's wrong with that?
> > > >
> > > > Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100:
> > > > > Is there a direct way (via cmd line) to find out the revisions
> > involved
> > > > in
> > > > > the summary result of differencing two branches?
> > > > >
> > > > > An easy example:
> > > > >
> > > > >
> > > > > ========================
> > > > >
> > > > > svn diff
> > > > >
> > > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos
> > > > >
> > > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize
> > > > >
> > > > > M
> > > > >
> > > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c
> > > > >
> > > > > ========================
> > > > >
> > > > > The two tags were created in r1036188 and r1038150, but the replay.c
> > file
> > > > > was modified in
> > > > >
> > > >
> > http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/replay.c@1037005
> > > > >
> > > > > Is there anyway to find out the 1037005 revision number without
> > having to
> > > > > analyze the logs?
> > > >
> >
Received on 2010-12-22 16:11:36 CET