You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Johannes Egger <jo...@tigerlair.net> on 2008/01/31 10:06:33 UTC
automatic server-side setting of svn:keywords using hooks
Dear List,
I've recently been wondering whether there's a way to automatically add specific svn:keywords
properties to non-binary files on the server side. I know about auto-prop support, but it only
works on the client side.
After some digging I found this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=1974
which is somewhat related to what I want to do, but not exactly.
Anyway, since propagating specific configuration settings to clients is not yet supported, I'm
wondering whether one could modify the transaction in a commit hook to set svn:keywords="Id Author
Date" for all *new* (added) non-binary files. One could check whether the file is non-binary using
the 'file' unix command, or specify a number of file suffixes that are known text files (e.g. "pl
plx pm css htm html js cpp c h java").
I saw a big warning at http://svnbook.red-bean.com/en/1.1/ch05s02.html (subversion 1.1) about
modifying a transaction using hook scripts. The 1.1 version of the book specifically mentions
svn:eol-style and svn:mime-type. This is understandable.
Version 1.4 is more explicit and talks about the client-side cache which might become stale. Is
this a problem for *all* transaction modifications? Does it apply to svn-keywords?
Is there any other way to automatically set properties on the server-side that I'm not aware of?
Best regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: automatic server-side setting of svn:keywords using hooks
Posted by Talden <ta...@gmail.com>.
> > I saw a big warning at http://svnbook.red-bean.com/en/1.1/ch05s02.html (subversion 1.1) about
> > modifying a transaction using hook scripts. The 1.1 version of the book specifically mentions
> > svn:eol-style and svn:mime-type. This is understandable.
> >
> > Version 1.4 is more explicit and talks about the client-side cache which might become stale. Is
> > this a problem for *all* transaction modifications? Does it apply to svn-keywords?
>
> Yes, it's a problem for all transaction modifications: all file and
> directory properties are cached on the client. The only server side
> commit-time modification which is relatively safe (for now) is to
> change revision properties. (But those don't have any relation with
> keywords.)
>
> > Is there any other way to automatically set properties on the server-side that I'm not aware of?
>
> Yes, in a followup commit following the commit that didn't set the
> correct keywords.
It would be nice if this could be assured to be the very next commit
and that the change could be seen as a commit correction by committer
immediately (an automatic update of those paths only). Essentially
have a committing hook (potentially a new hook that occurs during
commit after pre-commit has approved the commit attempt) that may or
may not append a commit alterations revision and attach this in the
commit response.
I'm aware this would violate the policy of a single command only
sending changes one direction but it seems to me that, being a
centralised VCS, it doesn't violate the clients understanding of
current state of those files/folders as long as the hook is only
allowed to change paths that were changed in the original commit.
Doing it this way ensures there can be no intervening commit and
therefore never a conflict case for this hook generated commit.
NB: The corrective commit would not be allowed to make tree
modifications (un-deleting, adding, copying or moving files/folders)
as there's no assurance that the clients working copy has the relevent
paths up to date and this could produce side-effects outside the scope
of the original commit.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: automatic server-side setting of svn:keywords using hooks
Posted by km...@rockwellcollins.com.
Ryan Schmidt <su...@ryandesign.com> wrote on 01/31/2008
01:19:02 PM:
> On Jan 31, 2008, at 12:50, Johannes Egger wrote:
> >>> I saw a big warning at http://svnbook.red-bean.com/en/1.1/
> >>> ch05s02.html (subversion 1.1) about
> >>> modifying a transaction using hook scripts. The 1.1 version of
> >>> the book specifically mentions
> >>> svn:eol-style and svn:mime-type. This is understandable.
> >>>
> >>> Version 1.4 is more explicit and talks about the client-side
> >>> cache which might become stale. Is
> >>> this a problem for *all* transaction modifications? Does it apply
> >>> to svn-keywords?
> >>
> >> Yes, it's a problem for all transaction modifications: all file and
> >> directory properties are cached on the client. The only server side
> >> commit-time modification which is relatively safe (for now) is to
> >> change revision properties. (But those don't have any relation with
> >> keywords.)
> >>
> >>> Is there any other way to automatically set properties on the
> >>> server-side that I'm not aware of?
> >>
> >> Yes, in a followup commit following the commit that didn't set the
> >> correct keywords.
> >
> > Thanks for your quick response. How would I go about doing that?
> > The commit hooks are only passed
> > the repo path and revision id as arguments. Would I have to check
> > which files have been added with
> > that revision id, then add svn:keywords properties and commit? E.g.
> > I'd parse the output of "svn
> > log" or some similar command etc?
>
> In the post-commit hook, you would check which files have been added/
> changed/deleted using
>
> svnlook changed $REPO -r $REV
>
> Your hook would need to maintain a working copy for itself somewhere
> on the server. It could update each directory that was changed, which
> you can find using
>
> svnlook dirs-changed $REPO -r $REV
>
> Then for each file changed, set the property. Then commit all changes.
I *thought* that the upcoming 1.5 was supposed to support
"svn propset PROPNAME PROPVAL URL" syntax.
If it does, it will make it a lot simpler to do these post-commit hook
property settings. (I.E. no server side working copy would be required)
For those working with large files this is a big win.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: automatic server-side setting of svn:keywords using hooks
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 31, 2008, at 12:50, Johannes Egger wrote:
>>> I saw a big warning at http://svnbook.red-bean.com/en/1.1/
>>> ch05s02.html (subversion 1.1) about
>>> modifying a transaction using hook scripts. The 1.1 version of
>>> the book specifically mentions
>>> svn:eol-style and svn:mime-type. This is understandable.
>>>
>>> Version 1.4 is more explicit and talks about the client-side
>>> cache which might become stale. Is
>>> this a problem for *all* transaction modifications? Does it apply
>>> to svn-keywords?
>>
>> Yes, it's a problem for all transaction modifications: all file and
>> directory properties are cached on the client. The only server side
>> commit-time modification which is relatively safe (for now) is to
>> change revision properties. (But those don't have any relation with
>> keywords.)
>>
>>> Is there any other way to automatically set properties on the
>>> server-side that I'm not aware of?
>>
>> Yes, in a followup commit following the commit that didn't set the
>> correct keywords.
>
> Thanks for your quick response. How would I go about doing that?
> The commit hooks are only passed
> the repo path and revision id as arguments. Would I have to check
> which files have been added with
> that revision id, then add svn:keywords properties and commit? E.g.
> I'd parse the output of "svn
> log" or some similar command etc?
In the post-commit hook, you would check which files have been added/
changed/deleted using
svnlook changed $REPO -r $REV
Your hook would need to maintain a working copy for itself somewhere
on the server. It could update each directory that was changed, which
you can find using
svnlook dirs-changed $REPO -r $REV
Then for each file changed, set the property. Then commit all changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: automatic server-side setting of svn:keywords using hooks
Posted by Johannes Egger <jo...@tigerlair.net>.
[...]
>> I saw a big warning at http://svnbook.red-bean.com/en/1.1/ch05s02.html (subversion 1.1) about
>> modifying a transaction using hook scripts. The 1.1 version of the book specifically mentions
>> svn:eol-style and svn:mime-type. This is understandable.
>>
>> Version 1.4 is more explicit and talks about the client-side cache which might become stale. Is
>> this a problem for *all* transaction modifications? Does it apply to svn-keywords?
>
> Yes, it's a problem for all transaction modifications: all file and
> directory properties are cached on the client. The only server side
> commit-time modification which is relatively safe (for now) is to
> change revision properties. (But those don't have any relation with
> keywords.)
>
>> Is there any other way to automatically set properties on the server-side that I'm not aware of?
>
> Yes, in a followup commit following the commit that didn't set the
> correct keywords.
Thanks for your quick response. How would I go about doing that? The commit hooks are only passed
the repo path and revision id as arguments. Would I have to check which files have been added with
that revision id, then add svn:keywords properties and commit? E.g. I'd parse the output of "svn
log" or some similar command etc?
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: automatic server-side setting of svn:keywords using hooks
Posted by Erik Huelsmann <eh...@gmail.com>.
On 1/31/08, Johannes Egger <jo...@tigerlair.net> wrote:
>
> Dear List,
>
> I've recently been wondering whether there's a way to automatically add specific svn:keywords
> properties to non-binary files on the server side. I know about auto-prop support, but it only
> works on the client side.
>
> After some digging I found this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=1974
> which is somewhat related to what I want to do, but not exactly.
>
> Anyway, since propagating specific configuration settings to clients is not yet supported, I'm
> wondering whether one could modify the transaction in a commit hook to set svn:keywords="Id Author
> Date" for all *new* (added) non-binary files. One could check whether the file is non-binary using
> the 'file' unix command, or specify a number of file suffixes that are known text files (e.g. "pl
> plx pm css htm html js cpp c h java").
>
> I saw a big warning at http://svnbook.red-bean.com/en/1.1/ch05s02.html (subversion 1.1) about
> modifying a transaction using hook scripts. The 1.1 version of the book specifically mentions
> svn:eol-style and svn:mime-type. This is understandable.
>
> Version 1.4 is more explicit and talks about the client-side cache which might become stale. Is
> this a problem for *all* transaction modifications? Does it apply to svn-keywords?
Yes, it's a problem for all transaction modifications: all file and
directory properties are cached on the client. The only server side
commit-time modification which is relatively safe (for now) is to
change revision properties. (But those don't have any relation with
keywords.)
> Is there any other way to automatically set properties on the server-side that I'm not aware of?
Yes, in a followup commit following the commit that didn't set the
correct keywords.
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org