You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2007/06/26 10:37:13 UTC
Should we maintain the backward comaptiblity with Subversion Operational
Logging?
Hi All,
The recent enhancements to Subversion operational logging to trunk won't
be backward compatible.
I am attaching difference in logs of 1.5.0-dev and 1.4.4.
Maintaining the backward compatibility may be possible if we add new
fields at the end.(Depends on how people parse it).
But I have one more improvement in mind that won't allow adding fields
at the end.
The improvement is consistent style of fields like revision should be
the last field, so that parsing would be easier.
i.e In 1.5.0-dev for 'checkout' we added revision number for commit and
we added the 'common-parent-of changed-paths' to commit, adding this new
info at the end would break the above improvement of consistent logging.
1.4.4 1.5.0-dev
-----------------------------------------------------------------
commit r8 commit
'/trunk' r8
list-dir /trunk list-dir
'/trunk' r8
blame /trunk/test.c blame
'/trunk/test.c' r8:17
diff-or-merge '/left_path' '/right_path' diff-or-merge '/trunk'
r5:9 Or diff-or-merge '/left_path@84' '/right_path@94'
switch '/source_path' '/destination_path' switch '/left_path@84'
'/right_path@94'
checkout-or-export '/trunk' checkout-or-export
'/trunk' r8
update '/trunk' update
'/trunk' r8
remote-status '/trunk' remote-status
'/trunk' r8
log-all '/trunk' log
'/trunk,/branches/abc' r8:18"
log-partial '/trunk' log
'/trunk,/branches/abc' r8:18"
In summary I would like to go-ahead with the format of
'command path(s) rREV".
This needs a change to 'revprop-change' log and 'replay'
revprop-change r8, 'svn:log' -> revprop-change 'svn:log' r8
replay 8 '/trunk' -> replay '/trunk' r8
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should we maintain the backward comaptiblity with Subversion Operational Logging?
Posted by Daniel Rall <dl...@collab.net>.
We've never promised that we'd retain backwards compat in the output
of our operational logging. Given how much information was missing in
its first release, I don't think that we should bother to try yet.
Re: Should we maintain the backward comaptiblity with Subversion
Operational Logging?
Posted by Kamesh Jayachandran <ka...@collab.net>.
>>
>>> But I have one more improvement in mind that won't allow adding fields at
>>> the end.
>>> The improvement is consistent style of fields like revision should be the
>>> last field, so that parsing would be easier.
>>> i.e In 1.5.0-dev for 'checkout' we added revision number for commit and we
>>> added the 'common-parent-of changed-paths' to commit, adding this new info
>>> at the end would break the above improvement of consistent logging.
>>>
>> I couldn't parse that, sorry.
>>
>
> I think Kamesh is saying that there are two routes we might takes with this
> logging stuff:
>
> - add new items at the ends of their respective lines, as a sort of
> backwards-compat attempt
>
> - have revisions always be at the ends of lines, for more consistent
> parsing
>
> and then he points out that the two routes are already in conflict because
> in 1.5.0-dev we've added new fields that aren't revisions.
>
>
Thanks Mike for clarifying, that is what I meant.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should we maintain the backward comaptiblity with Subversion
Operational Logging?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Jun 26, 2007 at 08:02:06AM -0400, C. Michael Pilato wrote:
> I think Kamesh is saying that there are two routes we might takes with this
> logging stuff:
>
> - add new items at the ends of their respective lines, as a sort of
> backwards-compat attempt
>
> - have revisions always be at the ends of lines, for more consistent
> parsing
>
Ah, right. I like the third option: add new items in the most logical
place for the operation in question so that the logs remain readable.
I haven't done any logs analysis with the SVN operation logs, but I
would have thought that anything non-trivial would need to deal with the
different formats of the different commands anyway, so a semi-common log
format doesn't seem that attractive to me. YMMV (and like I said, I'm
not actually trying to do this).
Regards,
Malcolm
Re: Should we maintain the backward comaptiblity with Subversion
Operational Logging?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe wrote:
> On Tue, Jun 26, 2007 at 04:07:13PM +0530, Kamesh Jayachandran wrote:
>> The recent enhancements to Subversion operational logging to trunk won't be
>> backward compatible.
>
> I don't really know how much of a problem that is - did we ever promise
> that it would be?
>
>> But I have one more improvement in mind that won't allow adding fields at
>> the end.
>> The improvement is consistent style of fields like revision should be the
>> last field, so that parsing would be easier.
>> i.e In 1.5.0-dev for 'checkout' we added revision number for commit and we
>> added the 'common-parent-of changed-paths' to commit, adding this new info
>> at the end would break the above improvement of consistent logging.
>
> I couldn't parse that, sorry.
I think Kamesh is saying that there are two routes we might takes with this
logging stuff:
- add new items at the ends of their respective lines, as a sort of
backwards-compat attempt
- have revisions always be at the ends of lines, for more consistent
parsing
and then he points out that the two routes are already in conflict because
in 1.5.0-dev we've added new fields that aren't revisions.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Should we maintain the backward comaptiblity with Subversion
Operational Logging?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Malcolm Rowe wrote:
> On Tue, Jun 26, 2007 at 04:07:13PM +0530, Kamesh Jayachandran wrote:
>
>> The recent enhancements to Subversion operational logging to trunk won't be
>> backward compatible.
>>
>
> I don't really know how much of a problem that is - did we ever promise
> that it would be?
>
>
I could not see any such promise.
>> But I have one more improvement in mind that won't allow adding fields at
>> the end.
>> The improvement is consistent style of fields like revision should be the
>> last field, so that parsing would be easier.
>> i.e In 1.5.0-dev for 'checkout' we added revision number for commit and we
>> added the 'common-parent-of changed-paths' to commit, adding this new info
>> at the end would break the above improvement of consistent logging.
>>
>
> I couldn't parse that, sorry.
>
Thanks Mike for clarifying what I meant.
>
>> 1.4.4 1.5.0-dev
>> -----------------------------------------------------------------
>> commit r8 commit '/trunk'
>> r8
>> list-dir /trunk list-dir
>> '/trunk' r8
>> blame /trunk/test.c blame
>> '/trunk/test.c' r8:17
>> diff-or-merge '/left_path' '/right_path' diff-or-merge '/trunk' r5:9
>> Or diff-or-merge '/left_path@84' '/right_path@94'
>> switch '/source_path' '/destination_path' switch '/left_path@84'
>> '/right_path@94'
>>
>> In summary I would like to go-ahead with the format of
>> 'command path(s) rREV".
>>
>
> While that's not a bad idea, I don't think we can shoehorn all possible
> commands into that format. See, for example, the diff and switch
> commands above. But I'm all for consistency when there's no reason not
> to switch.
>
>
Yes it may not be possible always, but wherever possible we should.
>> This needs a change to 'revprop-change' log and 'replay'
>> revprop-change r8, 'svn:log' -> revprop-change 'svn:log' r8
>>
>
> I'm -0 on that change: svn:log isn't a path, and for revprop-changes the
> revision is the immediate target of the change.
>
Yes. In concept I agree with you.
But having consistent representation would ease the parsing of this data
with single regex something like(not a complete one)
regex = '(?P<command>.*?) \'(?P<path_or_rev_prop>.*?)\'
(r(?P<revno>\d*))*'.
>
>> replay 8 '/trunk' -> replay '/trunk' r8
>>
>
> On the other hand, that looks like a good change to make.
>
Fixed in r25542.
Thanks
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Should we maintain the backward comaptiblity with Subversion
Operational Logging?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Tue, Jun 26, 2007 at 04:07:13PM +0530, Kamesh Jayachandran wrote:
> The recent enhancements to Subversion operational logging to trunk won't be
> backward compatible.
I don't really know how much of a problem that is - did we ever promise
that it would be?
> But I have one more improvement in mind that won't allow adding fields at
> the end.
> The improvement is consistent style of fields like revision should be the
> last field, so that parsing would be easier.
> i.e In 1.5.0-dev for 'checkout' we added revision number for commit and we
> added the 'common-parent-of changed-paths' to commit, adding this new info
> at the end would break the above improvement of consistent logging.
I couldn't parse that, sorry.
>
> 1.4.4 1.5.0-dev
> -----------------------------------------------------------------
> commit r8 commit '/trunk'
> r8
> list-dir /trunk list-dir
> '/trunk' r8
> blame /trunk/test.c blame
> '/trunk/test.c' r8:17
> diff-or-merge '/left_path' '/right_path' diff-or-merge '/trunk' r5:9
> Or diff-or-merge '/left_path@84' '/right_path@94'
> switch '/source_path' '/destination_path' switch '/left_path@84'
> '/right_path@94'
>
> In summary I would like to go-ahead with the format of
> 'command path(s) rREV".
While that's not a bad idea, I don't think we can shoehorn all possible
commands into that format. See, for example, the diff and switch
commands above. But I'm all for consistency when there's no reason not
to switch.
> This needs a change to 'revprop-change' log and 'replay'
> revprop-change r8, 'svn:log' -> revprop-change 'svn:log' r8
I'm -0 on that change: svn:log isn't a path, and for revprop-changes the
revision is the immediate target of the change.
> replay 8 '/trunk' -> replay '/trunk' r8
On the other hand, that looks like a good change to make.
Regards,
Malcolm