[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: how is svn:author set?

From: Shannon Kerr <shannonckerr_at_gmail.com>
Date: Thu, 3 Jul 2008 04:33:39 -0500

OK, yea I think you are right. I don't want to just set svn:keywords, I
want to be able to go to the server and do:

svn propget svn:author foo.txt

to find out the author of the last revision after a client committed their
changes. Since this is not versioned, I take it that there is no way to
know the author of each revision without scanning "svn log"?

Thanks,

Shannon

On Thu, Jul 3, 2008 at 4:29 AM, Ryan Schmidt <
subversion-2008c_at_ryandesign.com> wrote:

> On Jul 3, 2008, at 04:17, Shannon Kerr wrote:
>
>
> On Thu, Jul 3, 2008 at 4:02 AM, Eric Lee wrote:
>>
>
> Shannon Kerr wrote:
>>>
>>>> I'm new to Subversion. When I do a proplist for an element I don't see
>>>> that svn:author is set. My setup is Subversion 1.5.0 + Apache + SSL. In
>>>> fact the only property I see set is the one that I am setting in the
>>>> TortoiseSVN config file which is mime-type. Is svn:author, the author of
>>>> the latest revision for that element, something that I have to set? If so,
>>>> where is the appropriate location to set this property? Basically, I don't
>>>> see svn:author set and I want it set for each revision.
>>>>
>>>>
> You could use svn:keywords to recursive set author
>>>
>>> e.g.
>>>
>>> aderic_at_PGERIC $ svn ls trunk -v
>>> 17 pgeric 40 Jul 02 22:48 delfile.txt
>>> 15 pgeric 271 Jul 02 02:10 test1.txt
>>> 8 pgeric 165 Jul 01 12:52 test2.txt
>>>
>>>
>>> aderic_at_PGERIC $ svn propset svn:keywords author trunk -R
>>> property 'svn:keywords' set (recursively) on 'trunk'
>>>
>>>
>>> aderic_at_PGERIC $ svn proplist trunk -R
>>> Properties on 'trunk\test2.txt':
>>> svn:keywords
>>> svn:eol-style
>>> Properties on 'trunk\delfile.txt':
>>> svn:keywords
>>> svn:eol-style
>>> Properties on 'trunk\test1.txt':
>>> svn:keywords
>>> svn:eol-style
>>>
>>>
>>> or by use config file in %AppData%\subversion\ folder on windows.
>>>
>>> config file
>>>
>>> [miscellany]
>>> enable-auto-props = yes
>>>
>>>
>>> [auto-props]
>>> *.c = svn:eol-style=LF;svn:keywords=Author Date Id Revision URL
>>>
>>>
>>>
>>> Please check out this subversion book also
>>> http://svnbook.red-bean.com/
>>>
>>
>
> So now we're talking about something different than Shannon's initial
> question which I answered a moment ago. Now we're talking about how to
> automatically set svn:keywords on files.
>
> I think I see. So if I set in my local (client-side) config file
>>
>> *.c = svn:keywords=Author Date Id Revision URL
>>
>> Those values will be set for each C file at each commit if the config file
>> had this line at the time the element was imported or added to the
>> repository right?
>>
>
> Yes.
>
> Does that mean that if I change "*.c" to "*.*" those properties would be
>> set for all elements at each commit?
>>
>
> All elements that have a period in their name, yes, but you probably do not
> want to set svn:keywords or svn:eol-style on binary files. So you probably
> should not have an auto-props definition matching * or *.*. Instead, define
> a rule for each file extension that is a text file (if you want the
> properties on all text files).
>
> Is there anyway to do this server side so I don't have to have each user
>> setup their local config file to support this? I suppose I can do this via
>> a hook, but I would hope there is an easier way.
>>
>
> No, the only way is via auto-props in the client-side config file. There is
> no way to do it on the server side. What you can do server-side is to write
> a pre-commit hook which rejects the commit of any file whose properties
> don't match your requirements. The error message your hook script prints out
> can inform your users how to set up their config file properly, or guide
> them to a correctly-configured config file they can download and install.
>
>
Received on 2008-07-03 11:34:07 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.