On 06/23/2011 07:18 PM, Dirk Thomas wrote:
> Well, since issue 3931 was fixed today
> ('svn log' is returning log of unrelated path when peg revision is not
> related to operative revision)
> i revisited my patch for issue 3830.
>
>
> + /* try fetching ra_session again
> + * this time with modif
Well, since issue 3931 was fixed today
('svn log' is returning log of unrelated path when peg revision is not related
to operative revision)
i revisited my patch for issue 3830.
+ /* try fetching ra_session again
+ * this time with modified revision argument.
+ * @todo modify already existing
Dirk Thomas writes:
> +/* find the revision at which the node was deleted
> + and sets *REVISION_DELETED to that revision. */
> +static svn_error_t *
> +check_for_deleted_rev(svn_ra_session_t *ra_session,
> + const char *url_or_path,
> + svn_revnum_t pe
I know everybody is quite busy due to the upcoming release.
But is there any chance that this patch - which improves svn log for forward
revision ranges - will make it into SVN before this and be part of 1.7.0?
Dirk
Thank you for your feedback, Philip.
I have attached an updated patch.
A short comment along the lines 'Sets *REVISION_DELETED ...'
I have added a comment for function check_for_deleted_rev.
No whitespace before ')'.
Split long line before '&& session_opt_revnum'
I have updated the for
Dirk Thomas writes:
A short comment along the lines 'Sets *REVISION_DELETED ...'
> +static svn_error_t *
> +check_for_deleted_rev(svn_ra_session_t *ra_session,
> + const char *url_or_path,
> + svn_revnum_t peg_revnum,
> + svn_revnum_
I have updated the patch of "libsvn_client/log.c" according to your suggestions.
Additionally i have added a test to "tests/cmdline/log_tests.py" to check for
desired results.
The newly added test will pass when the above enhancement has been applied
(other tests also pass).
The combined patch
Could someone of the devs please take a closer look?
I am willing to improve the patch based on concrete suggestions.
[...]
Sure thing. I can see where you're going with the patch. I haven't taken
the time to fully consider the appropriate, so consider the following a
syntactical patch review
On 05/30/2011 07:52 AM, Avalon wrote:
> Could someone of the devs please take a closer look?
> I am willing to improve the patch based on concrete suggestions.
[...]
Sure thing. I can see where you're going with the patch. I haven't taken
the time to fully consider the appropriate, so consider
Avalon writes:
> i have attached a patch to the issue tracker (see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3830) and tested
> the described use cases:
> svn log -rX:Y PATH@PEG
> - where Y > X and Y > PEG even if PATH@PEG has been deleted in revision Z,
> where PEG < Z < Y
>
For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision
in
which PATH@THAT-REV *did* exist, and continue the operation. I believe
this
is something that we can reasonably achieve without too much trouble and,
more
There are now two different issues brought up in these thread:
1. For 'svn log -rX:Y PATH@PEG, where Y>PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision
in
which PATH@THAT-REV *did* exist, and continue the operation. I believe
this
is som
On Thu, May 19, 2011 at 4:18 PM, Avalon wrote:
> I wanted to take a closer look into implementing this feature and have built
> the current SVN trunk.
> I have looked through the code and now i have a rough understanding how the
> log information is collected.
>
>> There are now two different issu
I wanted to take a closer look into implementing this feature and have built
the current SVN trunk.
I have looked through the code and now i have a rough understanding how the log
information is collected.
> There are now two different issues brought up in these thread:
>
> 1. For 'svn log -rX
On Wed, 09 Mar 2011, Avalon wrote:
[quoting cmpilato:]
2. Consider deletion events as "interesting history points"
when displaying the revisions logs for a given path. [...]
BTW, I don't think that solving (2) is realistic at this point.
But filing an issue about it cannot hurt.
Since i h
1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision in
which PATH@THAT-REV *did* exist, and continue the operation. I believe this
is something that we can reasonably achieve without too much trouble an
On Tue, Mar 08, 2011 at 05:05:10PM +0100, Avalon wrote:
> >There are now two different issues brought up in these thread:
> >
> >1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
> >doesn't exist. Instead, automatically substitute for Y the last revision in
> >which PATH@THAT
There are now two different issues brought up in these thread:
1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision in
which PATH@THAT-REV *did* exist, and continue the operation. I believe this
is somet
On 03/08/2011 05:11 AM, Avalon wrote:
> I would appreciate the feature since it would also be very useful for tools
> like WebSVN.
> How realistic would it be to get it implemented in the near future?
> While having good programming skill i have never compiled subversion myself.
> But if any help i
I believe that users expect
svn log -rREV1:REV2 path@PEG
to mean "report everything that happened to path@REV between
revision REV1 and REV2, inclusive", with both creation and deletion
being events for potential inclusion in the report. It's unfriendly
for "path@PEG does not exist in revis
On Tue, Mar 08, 2011 at 09:38:02AM +0200, Alan Barrett wrote:
> On Mon, 07 Mar 2011, Stefan Sperling wrote:
> I believe that users expect
>
>svn log -rREV1:REV2 path@PEG
>
> to mean "report everything that happened to path@REV between
> revision REV1 and REV2, inclusive", with both creation a
On Mon, 07 Mar 2011, Stefan Sperling wrote:
By asking for beta@4 with a revision range of 1:HEAD, we're
asking an invalid question because the revision range is not
valid for this path. There is no log to show in HEAD, so it
errors out (you can think of this as the filter trying to
eliminate
I am explicitly interest in finding a more recent revision than N of a
specific resource.
svn log -r N:HEAD path-of-resource@N
It is possible to find older revision (-r N:1 path@N) and the resource must
not exist in revision one.
I think you essentially want Subversion to apply some more heu
On 03/07/2011 09:14 AM, Avalon wrote:
> I am explicitly interest in finding a more recent revision than N of a
> specific resource.
> svn log -r N:HEAD path-of-resource@N
>
> It is possible to find older revision (-r N:1 path@N) and the resource must
> not exist in revision one.
I think you ess
For the svn log command the direction "-r N:1" works fine - even if the
resource does NOT exist in revision one.
So in this case the resource is NOT checked to exist in both start and end
revision.
For the forward case the existance in the end revision seems to be checked
indeed.
This is what
On Mon, Mar 07, 2011 at 01:29:29PM +0100, Avalon wrote:
> For the svn log command the direction "-r N:1" works fine - even if the
> resource does NOT exist in revision one.
> So in this case the resource is NOT checked to exist in both start and end
> revision.
>
Ah, I think I see where your pr
Hi Stefan,
i am using the svn log command with a "forward" revision range, e.g. "-r
N:HEAD".
This fails if the requested path has been deleted in HEAD revision.
When used with "backward" ranges, which are commonly used, e.g. "-r N:1", the
result is ok - even if the requested path is not prese
On Mon, Mar 07, 2011 at 01:09:17PM +0100, Avalon wrote:
> >i am using the svn log command with a "forward" revision range, e.g. "-r
> >N:HEAD".
> >This fails if the requested path has been deleted in HEAD revision.
> >
> >When used with "backward" ranges, which are commonly used, e.g. "-r N:1",
>
i am using the svn log command with a "forward" revision range, e.g. "-r
N:HEAD".
This fails if the requested path has been deleted in HEAD revision.
When used with "backward" ranges, which are commonly used, e.g. "-r N:1", the
result is ok - even if the requested path is not present in revisio
On 06.03.2011 11:12, Avalon wrote:
> Hi,
>
> i am using the svn log command with a "forward" revision range, e.g.
> "-r N:HEAD".
> This fails if the requested path has been deleted in HEAD revision.
>
> When used with "backward" ranges, which are commonly used, e.g. "-r
> N:1", the result is ok - e
Hi,
i am using the svn log command with a "forward" revision range, e.g. "-r
N:HEAD".
This fails if the requested path has been deleted in HEAD revision.
When used with "backward" ranges, which are commonly used, e.g. "-r N:1", the
result is ok - even if the requested path is not present in re
31 matches
Mail list logo
