Problem with the repository: bogus date

Landon Fuller landonf at
Fri Sep 7 14:16:53 PDT 2007

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. :-)
>> 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url :

More information about the macports-dev mailing list