Problem with the repository: bogus date

[Blair Zajac]

Landon Fuller wrote:
> 
> On Sep 7, 2007, at 09:43, Rainer Müller wrote:
> 
>> Landon Fuller wrote:
>>>
>>> On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
>>>
>>>>> Very sorry! That was my fault. I've now fixed the svn:date property
>>>>> of revision 2 so the log should work again. The timestamp of revision
>>>>> 1 and revision 3 are identical, so I set revision 2 to that same
>>>>> timestamp.
>>>>>
>>>>> (I issued a bad "svn propset" command the other day. I was meaning to
>>>>> change my own repo but I was missing an argument or something and
>>>>> then I couldn't figure out what I'd done. I must've been in my dports
>>>>> tree when I issued the command.)
>>>>
>>>> Oh, and I wanted to say: if we had the post-revprop-change email hook,
>>>> I would've noticed and been able to fix the problem right away. :-)
>>>>
>>>> http://trac.macports.org/projects/macports/ticket/12593
>>>
>>> Maybe the repository shouldn't allow unrevisioned property changes at
>>> all? It seems like a good way to stomp on version history.
>>
>> It's nice to fix typos in log messages. But it could be limited to
>> svn:log for that purpose with a pre-revprop-change like this:
> 
> The log being unversioned, that still seems a dangerous tool to leave 
> open. Here at work, unrevisioned properties require local access to the 
> repository -- nobody else has this. I only recall one instance in the 
> past three years that I've been asked to change a commit log message on 
> behalf of any of our developers, and I've never done so for myself.
> 
> I'd personally rather have a few uncorrected typos in commit logs than 
> the potential for history-changing. Auditing the changes is an 
> improvement, but why even open the door?

We do this all the time in the Subversion's own repository.  The standard way of 
handling it is to use mailer.py to send a diff of the before and after log 
message to some list.  This can be set up in the post-revprop-change script.

It's common to edit log messages.  In fact, the recommended procedure for a 
reverse merge of a revision is to now go back and edit the log message on the 
reverted revision indicating that it was reverted and in which revision.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
http://www.orcaware.com/svn/