Re: Need possibilities to set Subversion property for keyword expansion

> -> desired would be solution c [:)]

This is NOT the desired solution. Doing "C" will result in your having
to do another commit in your repository in order to set up the
property. Thus, your pre-commit hook script will create another
repository revision. This means:

* You must CAREFULLY write your pre-commit hook not to execute when
your pre-commit hook tries to do a commit itself. Recursive pre-commit
executions is a good way to not only bring down your server, but to
corrupt your repository with thousands of revisions as your pre-commit
hook triggers itself over and over.

* Let developers know that they will now have to do an "svn update"
after each commit because what they have on their system after a
commit is not the latest and greatest revision. Now, instead of doing
a simple commit, they must now remember to do an update too which can
take another few minutes to do. If they don't, their commits will
fail, and they'll have to do an update.

This will cause the developers to make fewer big potentially build-
breaking commits instead of a bunch of small ones, and this is the
exact opposite you want your developers to be doing. Developers should
be making a series of small verifiable and testable changes -- changes
that do not break the build.

So, your attempt to "help" the developers do their work may end up
making them frustrated and causing issues in the development cycle.

And one more scenario which actually took place: There was a
pre-commit hook script that made sure that svn:keywords was set to
"Author Date". A developer added a file, and then set the svn:keyword
property to "Date Author". The developer then made a few more changes
in the recently added file and attempted to do another commit. Commit
failed because the developer didn't do an update.

The developer was then upset about that because doing an update will
take a few extra minutes, breaking his concentration. Now, when he did
an update, he got a change conflict. Developer then spends the next
few minutes comparing the revisions of the file looking for the
conflict. He can't find them. After a few more attempts, he realizes
the conflict was in the property setting. He compares the property
setting, and then loses it.

The developer had wasted about half an hour on this problem, and in
the end, the pre-commit hook made a change not because the developer
forgot to add the property. Not because the developer didn't put in
the two required properties, but because the developer didn't list the
two properties in the required order.

I was hired to replace that previous build manager who had setup that
pre-commit hook. He had left because he didn't get along with the
developers. My job was to remove the awful Subversion revision control
system and replace it with ClearCase which some of the developers were
pushing because it is a REAL revision control system and not some
piece of open source crap like Subversion.

And, even before I started the developers had already decided they
were not too fond of me either. I was going to be another build
manager who got in the way of their work.

I was able to delay the replacing of Subversion with ClearCase which
gave me time to remove most of the pre-commit hooks. We then trained
developers on using Subversion and sought out their opinions on how
they could best do their job. In the end, the developers were finally
more accepting of Subversion although still hated it because of their
earlier experience. At least the pressure to install ClearCase had
abated.

No, the proper way to handle this is to train the developers. Let them
know about the Subversion configuration file and how auto-properties
work. Give them a configuration file that sets all the needed
auto-properties. Let the developers install it. Let them know that if
they create a file and it doesn't have the property set, their commit
will fail. Let them know how to diagnose the failure and how to fix
the failure.

It's the way Subversion was meant to work, and trying to get around
this will cause a lot of heartaches and bad blood.

On Wed, May 13, 2009 at 3:36 AM, Ramachandran, Vishwanath(IE10)
<Vishwanath.Ramachandran_at_honeywell.com> wrote:
> Hi Ryan
>
> Pls confirm my assumption:
>
> 1 .Keyword expansion will be done on client side. (Replacing in
> "committed" document the "placeholder" with the keywords).
> 2. The client will do this action only if the svn property is set
> (stored in repository). If the svn-property is not set client is not
> doing any keyword expansion.
> 3. This property can be created in different ways:
> a.) manually (e.g. on client subversion -> property dialog -> new
> property -> snv: keyword expansion)
> b.) automated on client: -> if in autoprops the corresponding entries
> are set the property will be set once the first commit happens.
> c.) The way you proposed it -> on the server with a script which checks
> if the property is not already set -> and if not set -> set the
> property.
>
> ->a.) and b.) we are doing already and we know that it works ->
> disadvantage: For a.) -> manual work, for b.) -> all clients need to get
> the autoprops set -> which is also manual work on each client -> error
> prone.
>
> -> desired would be solution c [:)]
>
> Regards
> R.R.Vishwanath
> Desk: +91 80 26588360 Extn: 44211
> Cell: +91 9632243577
> ========================================================================
> ========================================================================
> ========
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009a_at_ryandesign.com]
> Sent: Friday, May 08, 2009 3:20 PM
> To: Ramachandran, Vishwanath(IE10)
> Cc: Campbell Allan; users_at_subversion.tigris.org
> Subject: Re: Need possibilities to set Subversion property for keyword
> expansion
>
> On May 8, 2009, at 00:37, Ramachandran, Vishwanath(IE10) wrote:
>
>> I need to know if it would be possible to make modifications on the
>> subversion server side for the repository in a way that everytime a
>> new
>> item is added to the repository it will get added (automatically on
>> server side) the property svn:needs-lock .
>>
>> I think that it is possible to locally set on the Tortoise client a
>> special setting in the config file in the section "auto-props". The
>> disadvantage with that is that each client has to do this on his
>> machine
>> seperately.
>>
>> First i need to have this information if this is possible to implement
>> on the server (and if you could do this)-> Pls let me know. Also i
>> need
>> the information if there are any side effects or disadvantages of
>> doing
>> this on the server.
>>
>> Before really setting up the repository i have to confirm you that we
>> really want to go this way
>
> Yes, you can do it on the server, but it is not recommended. You
> cannot (well, with language bindings maybe you can, but in any case
> you absolutely must not) change the incoming transaction. Therefore,
> your only option is to immediately commit a second revision to fix a
> preceding revision that does not have the correct properties set.
> This is difficult because the server must maintain a working copy in
> which to perform these changes, and there are race conditions to
> think about, not to mention the fact that a developer's working copy
> will be immediately outdated after committing, which the developer
> would not ordinarily expect.
>
> The better and recommended way is to do it on the client side in auto-
> props, as you already found, and then install a pre-commit hook on
> the server which rejects any commit which does not conform to your
> requirements. Developers will realize after the second or third time
> that maybe they should set up their auto-props.
>
>
>> I know that Keyword expansion is a client-side operation, and your
>> client only "knows" about changes which have occurred in the
>> repository
>> when you update your working copy to include those changes
>>
>> But What i want to get is just to get for each file the properties for
>> keyword expansion set ->directly on the server -> same as the property
>> snv:Need-lock has been set.
>
> Keyword expansion does not happen on the server. It happens on the
> client. This cannot be changed.
>
>
>> We want just to add the property "snv:keyword URL Rev Author Date" for
>> the file types *.doc, *.xls, *.mm, *.mpp, *. ppt. directly during
>> commiting (same as it is done for snv:need-lock).
>
> Do it as explained above. Use a combination of auto-props on the
> client for convenience and a pre-commit hook on the server to
> enforce. The property will be saved in the repository, and the
> keyword expansion will be done by the client on checkout or update.
>
> Note that the Subversion properties begin with "svn:" (for
> "SubVersioN"), not "snv:".
>
>
>> The description in the attached word file was just a "workaround"
>> which
>> we used today to reach that.
>
> I did not find an attachment on your email. If you do attach
> something, better not use Word format, as many here probably don't
> have Word. Text files are best, or for more complex documents a PDF
> would be ok.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2231298
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2239395
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].