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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
