Automatically add svn keyword properties for new files (server-side)
Asked Answered
J

3

13

I want to add svn properties (like svn:keyword=Id Date Rev Author) to files upon commits of new files.

For this to work there may be two main options:

  1. Client-side: altering the autoprops in the svn client configuration
  2. Server-side: do some magic with commit-hooks

The client side is not always desirable, as control over the client set up is needed. I want to solve this on the server. How can this be done.

Jetton answered 23/2, 2010 at 12:50 Comment(0)
P
6

The Subversion docs say it's a bad idea to modify a commit on the server side.

Instead, you could do something like a customized version of the svn_apply_autoprops script periodically through cron (or even on the server triggered by a commit). The svn_apply_autoprops script is a little more general than what you need, but it should be straighforward to set up the appropriate config file.

As of this post, the subversion web site is migrating under apache.org, and I couldn't find the docs for the contrib tools.

Punjabi answered 23/2, 2010 at 23:13 Comment(2)
The scrubbing cron script that modifies svn properties on files is my way to go. I have read the same comment on the 'modifying the commit'. For the moment I ask users to load a svn configuration script in their svn client (tortoisesvn).Jetton
Note that this is an old answer… the modern answer can also be found on this question: https://mcmap.net/q/880449/-automatically-add-svn-keyword-properties-for-new-files-server-sideBozo
A
2

Since version 1.8 one can use a feature repository dictated configuration to automatically set properties on server side.

From Automatic Property Setting:

[...] a set of property definitions which all connecting clients automatically consider when operating on working copies checked out from a given server. Subversion 1.8 and newer clients support such functionality through the svn:auto-props inheritable property.

Note that you only need new enough client. Below you'll find a complete example where I used svn command line client 1.8.8. with svn server 1.6.11.

svn client version 1.8+ required

jani@dev:/tmp/testrepo/text-files$ svn --version --quiet
1.8.8

Files created before auto-props property setting

jani@dev:/tmp/testrepo/text-files$ file f?.txt
f1.txt: UTF-8 Unicode text
f2.txt: UTF-8 Unicode text, with CRLF line terminators
f3.txt: ASCII text, with CRLF line terminators
jani@dev:/tmp/testrepo/text-files$    

Set auto-props

jani@dev:/tmp/testrepo/text-files$ svn propset svn:auto-props "*.txt = svn:eol-style=LF" .
property 'svn:auto-props' set on '.'
jani@dev:/tmp/testrepo/text-files$ svn proplist -v --recursive
Properties on '.':
  svn:auto-props
    *.txt = svn:eol-style=LF
jani@dev:/tmp/testrepo/text-files$    

Create new file f4.txt with CRLF line terminators

jani@dev:/tmp/testrepo/text-files$ file f?.txt
f1.txt: UTF-8 Unicode text
f2.txt: UTF-8 Unicode text, with CRLF line terminators
f3.txt: ASCII text, with CRLF line terminators
f4.txt: UTF-8 Unicode text, with CRLF line terminators
jani@dev:/tmp/testrepo/text-files$    

The line terminators of f4.txt changes after commit

jani@dev:/tmp/testrepo/text-files$ svn add f4.txt
A         f4.txt
jani@dev:/tmp/testrepo/text-files$ svn commit -m 'just another test' .
Adding         f4.txt
Transmitting file data .
Committed revision 5.
jani@dev:/tmp/testrepo/text-files$ file f?.txt
f1.txt: UTF-8 Unicode text
f2.txt: UTF-8 Unicode text, with CRLF line terminators
f3.txt: ASCII text, with CRLF line terminators
f4.txt: UTF-8 Unicode text
jani@dev:/tmp/testrepo/text-files$ svn proplist -v --recursive
Properties on '.':
  svn:auto-props
    *.txt = svn:eol-style=LF

Properties on 'text-files/f4.txt':
  svn:eol-style
    LF
jani@dev:/tmp/testrepo/text-files$
Ahmadahmar answered 27/10, 2016 at 10:45 Comment(0)
C
1

Anytime you have multiple people committing, you probably have inconsistent subversion configs.

Solve this problem twice, as you say, at the client level and the server level:

  1. Do NOT modify props automatically during server commit. This will almost certainly bite you in the butt later when you have an exception to your rule and you can't get past it.

  2. Send an email to all developers with directions for modifying their config files, as in:

    Attention, teammates:

    On ALL the boxes you work on, please modify the file:  ~/.subversion/config 

    * under the section [miscellany], uncomment the line: 
    enable-auto-props = yes

    under the section [auto-props], add or uncomment lines so they read:

    *.py = svn:eol-style="LF";svn:executable="ON";keywords="Id";

    Note: you may test this is working by doing the following in your sandbox directory:

    touch delete.me.py
    svn add delete.me.py
    ls -al delete.me.py   # you will see:
    -rwxrwxr-x 1 krice4 krice4    0 Apr 19 12:05 delete.me.py
    svn proplist delete.me.py  # you will see:
    Properties on 'delme.py':
      svn:executable
      keywords
      svn:eol-style
    svn revert delete.me.py
    rm delete.me.py

3.After sending the email, it's time to add a belt to those suspenders, because some developer is going to forget to do what they're supposed to do. So, create an annoying warning every time someone commits without setting props correctly.

I would advise the following detection hooks for Python files. All should print warnings NOT prevent the subversion operation, as noted above, the exceptions will kill you. Note that exceptions can send emails to the user, or email the entire development group, with the subject:

"Stupid user Kevin just committed a file with tabs in it!"

  • verify svn:executable ON
  • verify svn:keywords "Id"
  • verify svn:eol-style "LF" # linux systems
  • verify No Tabs In file ! (these mess with various things)

For how to write one of these commit hooks, see: http://wordaligned.org/articles/a-subversion-pre-commit-hook

Capps answered 19/4, 2013 at 17:26 Comment(2)
Prefer using tabs for indention in source files. So each team member can have her/his preferred tab-size (2, 4, ...) - My name is NOT Kevin ;-)Zama
IMHO, in Python, tabs are a giant horrible monster to defenestrate, slay, stomp on, fold, spindle, mutilate, and yell about. It might be okay to have ALL tabs and NO leading spaces, but we all know that's impossible on every line of every file. So, NEVER use them. All modern editors have settings to auto-replace 'em. CAUSE: Python handling of (line 1 w/ tabs and line 2 without tabs) is ambiguous and therefore bad-luck-drivien.Capps

© 2022 - 2024 — McMap. All rights reserved.