subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Hanley <jhan...@dgtlrift.com>
Subject Feature Request: revprop for "svn:client" Was: Tree conflict on Fresh checkout
Date Fri, 21 Jun 2013 18:22:12 GMT
After some digging into this issue - I am somewhat at a loss.  I'm not sure
how it happened but I can come up with a best guess that the user may have
checked in the change with 1.6.13 - my suspicion is there is an issue with
how the properties are stored, but unfortunately he has at lease 3
different machines he works from and has various different versions of SVN
and TortioiseSVN on each.

In hind site, if there was a revprop that included the version of the
client, if an artifact issue (such as this) is discovered in the
repository, this rev-prop can succinctly tell the administrator which
version of the client introduced the issue for reporting back to support.
It could also allow (via pre-commit hook script) the ability to "blacklist"
versions of the client that have issues.

It would also help to mitigate and correct issues as part of the upgrade
process for the server side if the server schema must be upgraded.

This would be a feature that would get the most benefit if it were
introduced across all versions of svn - 1.8, 1.7, 1.6, etc.

Upon check-in, the rev-prop would look something like:
user@node ~/projects/my_project
$ svn pl --revprop -r2734
https://svn.my_company.com/svn/my_project_fw/branches/int/my_project_03b
my_project_03b_pristine
Unversioned properties on revision 2734:
  svn:author
  svn:date
  svn:log
  svn:client

user@node ~/projects/my_project
$ svn pg svn:client --revprop -r2734
https://svn.my_company.com/svn/my_project_fw/branches/int/my_project_03b
svn, version 1.8.0 (r1490375) compiled Jun 19 2013, 10:42:54 on
i686-pc-cygwin



On Tue, Jun 11, 2013 at 4:12 PM, James Hanley <jhanley@dgtlrift.com> wrote:

> Is there any additional detail I can provide for this?
>
>
> On Thu, Jun 6, 2013 at 11:05 AM, James Hanley <jhanley@dgtlrift.com>wrote:
>
>> So, is there additional information I can provide - would doing a diff on
>> the properties of MkImage show anything useful.. I couldn't see any myself
>> but perhaps there's some flags to get additional detail?
>>
>>
>>
>> On Wed, Jun 5, 2013 at 5:00 PM, Andrew Reedick <
>> Andrew.Reedick@cbeyond.net> wrote:
>>
>>>
>>>
>>> > From: James Hanley [mailto:jhanley@dgtlrift.com]
>>> > Sent: Tuesday, June 04, 2013 1:44 PM
>>> > To: users@subversion.apache.org
>>> > Subject: Tree conflict on Fresh checkout
>>> >
>>> >  A    my_project_03b_pristine/Project/settings/MkSharedData.exe
>>> >   C my_project_03b_pristine/Project/settings/MkImage
>>> >   A my_project_03b_pristine/Project/settings/MkImage/main.c
>>> >   A my_project_03b_pristine/Project/settings/MkImage/defs.h
>>> >   A my_project_03b_pristine/Project/settings/MkImage/Makefile
>>> > A    my_project_03b_pristine/Project/settings/hex_to_hex.exe
>>> >
>>> > user_dude@computer_node~/projects/my_project/my_project_03b_pristine
>>> > $ svn status
>>> > D     C Project/settings/MkImage
>>> >      >   local unversioned, incoming add upon update
>>> > D       Project/settings/MkImage/Makefile
>>> > D       Project/settings/MkImage/defs.h
>>> > D       Project/settings/MkImage/main.c
>>> > Summary of conflicts:
>>> >  Tree conflicts: 1
>>>
>>> Duh.  The 'C' is in the 2nd column, which means there's a conflict with
>>> the properties.  However, I'm not sure why you would have a properties
>>> conflict on a checkout in svn 1.7.
>>>
>>>
>>>
>>>
>>
>

Mime
View raw message