You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pablo Beltran <pa...@svnflash.com> on 2010/12/20 18:22:20 UTC
Revisions being involved while comparing branches
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?
Re: Revisions being involved while comparing branches
Posted by Pablo Beltran <pa...@svnflash.com>.
On Wed, Dec 22, 2010 at 1:25 AM, Daniel Shahaf <d....@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?
>
> > 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.
>
>
I have solved it. Of course, I'm not a Subversion developer so I've used an
external tool for that. As it is 100% free tool I think there is not problem
announcing it at this mailing list.
Screenshot:
http://www.svnflash.com/components/com_ccboard/assets/uploads/62_9fa26b27449d15c07a49fc884484b5d1.jpg
At the web site (http://www.svnflash.com), there is also a Live Demo
publishing the Apache's Subversion repository at real time, so everybody can
see how it works.
For example, you can compare the future 1.7 release (trunk?) with the latest
1.6.15 release (tag) of the Subversion project and get the revisions for any
changed path.
Tip: Right click on any revision to see available commands (view, compare,
blame, revision graph,...)
> >
>
> HTH,
>
> Daniel
>
> > On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf <d.s@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?
> > >
>
Re: Revisions being involved while comparing branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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....@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@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?
> > > >
> >
Re: Revisions being involved while comparing branches
Posted by Pablo Beltran <pa...@svnflash.com>.
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....@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@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?
> > >
>
Re: Revisions being involved while comparing branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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?
> 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....@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?
> >
Re: Revisions being involved while comparing branches
Posted by Pablo Beltran <pa...@svnflash.com>.
Maybe the point is efficiency.
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?
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.
The goal is adding the involved revisions on the compare directories view of
TortoiseSVN and do it in the most efficient way.
On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf <d....@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?
>
Re: Revisions being involved while comparing branches
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
'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?