Problem with the repository: bogus date
landonf at macports.org
Fri Sep 7 14:41:57 PDT 2007
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.
- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070907/5e473342/PGP.bin
More information about the macports-dev