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 <[email protected]>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 [pat...@rev] > > 2. log u...@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 <[email protected] > > >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/repla...@1037005 > > > > > > > > > > Is there anyway to find out the 1037005 revision number without > > having to > > > > > analyze the logs? > > > > > >
