On Tuesday 08 February 2005 19:27, Philip Martin wrote:
> > The whole thing is currently triggered by auto-props and the config
> > option
>
> Auto-props are just a way of avoiding the need to run "svn propset".
Yes, you are right. The substitution of the property values is really
triggered by the existence of the properties themselves, ie. if svn:group
exists as a property, the file's group is set as value on commit.
> > "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:
> > [auto-props]
> > * = 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).
>
> So the presence of svn:group say is not enough, I also need to have
> use-commit-times set? That makes it different to svn:executable. I
> don't like the overload of use-commit-times either.
use-commit-times is used _only_ to determine if the stored properties should
be used on checkout/update.
The reason is that
- for software development with make-invocations it is undesirable to use
a stored modification time (because of the interactions with make) or the
file's mode, and normally impossible to change the owner (nobody develops
software as uid 0).
Here it possibly won't even make sense to *store* these properties.
- for some other purposes (archiving /etc, versioning /home, etc.) it is
*necessary* to store these informations - as they are needed for
restauration.
Imagine restoring /etc or /home and having to manually restore the owners,
groups and modes of the files ...
Especially /etc with it's variety of owners and groups needs this.
Of course, it's possibly to save the other informations somewhere else ...
say, "ls -laR /etc > /etc/.file_modes" and versioning that too.
But that's not a clean way, IMO.
> How does svn:unix-mode interact with svn:executable?
>
> How does svn:unix-mode interact with umask?
The saved mode is applied after svn:executable, ie. it overwrites it, and
ignores umask.
That's per design.
If I choose to save the mode of a file, it should be restored *as-is* and not
modified by something else I might forget in the haste.
> >> - 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 don't understand the your answer.
A file is choosen for commit because of text-changes.
*If* a file is going to be committed *and* the properties are set (to an
arbitrary value), the value get's set to the file's state.
I grant you that this isn't strictly correct; if I just change the permission
of a file it should be automatically found as a property change, and be
committed as " U file.txt".
This could be done by changing svn_wc__load_prop_file to check for this
special properties and substitute the current values.
> If I have the unix-mode stuff enabled is a "chmod" sufficient to cause
> commit to store the new permissions or do I need to do an explicit
> "svn propset"?
A "chmod" is sufficient *if* (currently, see above) the file has been changed.
> What happens if I "svn propset" one value and chmod a different value,
> does one of the values get committed or is a conflict detected?
The value in the working copy is mostly ignored, it's just necessary that it
exists.
> >> - 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.
>
> Auto-props are just a way of avoiding "svn propset". What happens if
> I "svn propset" one of your new properties on a directory?
It is left as-is and ignored. The patch currently just does files.
But you're right, directories have to have these versioned properties too.
> >> - 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.
> So if I do a chmod to have local modifications is "svn update" simply
> going to overwrite my changes?
That's a good question.
For my use-case I'd say yes, since the archived values have to have a higher
preference.
(After all, /etc will be archived per-machine; an update of /etc is done
mostly for recovery purposes, where the local state should be ignored.
Just the saved values are known to be valid).
On Tuesday 08 February 2005 19:50, C. Michael Pilato wrote:
> Is it considered in poor taste to register such a vague opinion such
> as:
>
> I think this "feature" is a horrendous idea.
>
> ?
As I said, this patch ain't complete yet. And I'd like to get some discussion
going about the "how to do this" (for the people who need this) instead of
discussing if I really want this :-) Ok? Please??
Please, try to see subversion in a bigger context than just software
development. It was a big leap to get use-commit-times; what I'm doing now is
just going further down that road.
In the past 2 years we had on dev@ and users@ several questions and requests
for this kind of automatic meta-data versioning. I believe there is demand
for it. (Apart from that, I need it too :-)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 9 08:30:34 2005