Problem with the repository: bogus date

[Landon Fuller]

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

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.

-landonf

-------------- 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 : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070907/5e473342/PGP.bin