Problem with the repository: bogus date

[Blair Zajac]

Landon Fuller wrote:
> 
> On Sep 7, 2007, at 14:29, Blair Zajac wrote:
> 
>> Landon Fuller wrote:
>>> On Sep 7, 2007, at 09:43, Rainer Müller wrote:
>>>> 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.
> 
> That's crazy talk! That sort of information is generally conveyed in bug 
> tracking systems, not by changing history in your source repository. It 
> may be common in the subversion project's usage, but I don't see why 
> it's an inherent necessity (or even a very good idea).

That's a crazy response :)

If you need to revert a bad commit for some reason, say the committer introduced 
a bug, why should it appear in a ticket?  It's not the natural place for it. 
For people that are looking at work that is done, it is nice to see in the 
commit log for the reverted revision that is was reverted.

Also, I don't think most open-source projects use ticket tracking systems to 
document the code they worked on, so that's another reason to allow log message 
changes.

We don't open a ticket in MacPorts or in svn just to document some new work that 
is going to happen, nor that I reverted something.

> Given that this discussion started with accidental destruction of a 
> non-revisioned historical property, it's obviously not an academic 
> concern. Two options:
>     - Treat the commit message as immutable as the commit itself.
> or
>     - Allow people to fix typos and change history, with the potential 
> for destructive changes.
> 
> The first option seems both simplier and safer, is the default 
> configuration, and is the standard expectation of a source control 
> system -- no data can be irretrievably lost.

That is the default for Subversion repositories.  I recommend that we allow log 
message changes, but only if the old and new log message are emailed somewhere.

Blair