No, this is different because he's modifying it before it's committed.
You'll break the checkout because the working copy that did the commit assumes
that what it sent to the server is exactly what will be committed. So if you do
an update later after another commit from another working copy was performed,
the diffs from the server may not apply cleanly to the working copy.
Now this is just a property change as Purple is saying, so I would guess the
changes are low of problems, but it's something you shouldn't do.
Blair
Lira Olavo wrote:
> Yes but isn't it the same as working within a team? It is like you
> commit something and then someone after you commit a new version, so
> your version now is not up-to-date. Why would you call it "break the
> checkout"?
>
> Olavo Lira
>
> -----Original Message-----
> From: Blair Zajac [mailto:blair_at_orcaware.com]
> Sent: Saturday, September 13, 2008 3:55 PM
> To: Purple Streak
> Cc: SVNUsers
> Subject: Re: Modifying file properties in pre-commit
>
> Purple Streak wrote:
>> Ok - I know that I _shouldn't_ ever do this, but putting that aside is
>> it actually physically possible, using say the python bindings, to
>> write a pre-commit hook that will add or amend a file property of one
>> of the files in the transaction?
>
> Well, yes, but you'll break the checkout you did the commit from since
> the
> server side copy is not the same as what it thinks it sent.
>
> Regards,
> Blair
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-13 23:47:09 CEST