I'm sorry for the delay.
I'll try to answer the questions you've sent; but I'll rearrange them a bit.
> Please provide a short description of the behaviour you intend to
> implement. Some questions:
> - Is there a way to enable/disable the behaviour?
The whole thing is currently triggered by auto-props and the config option
"use-commit-times". If eg. a property "svn:owner" is set on a file, it will
be sent to the repository as the current value.
So you'd have in your ~/.subversion/config something like this:
* = svn:text-time=yes;svn:owner=yes;svn:group=yes;svn:unix-mode=yes
or whatever values you'd like, and they'd be set on commit (and import).
> - If I change the owner/group/mode of the working copy does this get
> committed, or do I have to do an explicit propset?
On every commit because of text-changes the properties are set to the current
values. Currently this happens *only* on text-changes, but read below.
> - I assume the owner/group/mode of the working copy files get set
> during checkout, does it apply to directories as well?
As I work with auto-properties, and these (currently) work only with files.
But I thought about implementing auto-dir-props too.
> - Non-root Unix users cannot usually change ownership, does this cause
> lots of warnings or errors?
No, this is silently ignored.
> - Do updates modify the working copy owner/group/mode?
I believe it does; but I'm not sure. I can't test at the moment.
> - If an update changes the owner/group/mode does it generate conflicts
> with local changes, or do conflicts only occur if the wc properties
> are modified?
The conflict handling is currently unspecified.
But if these properties are handled like "svn:eol-style" (and cause a
re-translation of the file), the new values would be in effect immediately.
> > I did some amount of testing, but remarks are always appreciated.
> > (I know that a rewrite of libsvn_wc is planned which possibly does all
> > that, but as it may take some time I did a patch for the current code)
> A rewrite has been mentioned, but that doesn't mean it is planned.
> > * subversion-1.1.3.tstamp/subversion/include/svn_io.h
> We need a patch against trunk, not 1.1.3.
There you have me. It's not that simple for me to do that, as I'm behind a
I know that these patches are not complete right now; saving
directory-metadata needs some more work, and there'll be some other missing
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 7 08:30:11 2005