Osvaldo Pinali Doederlein wrote:
> On 24/04/2009 17:58, Blair Zajac wrote:
>>> Well originally I was thinking that it would be a very reasonable
>>> tradeoff to disable revprop editing on packed revisions. I think the
>>> majority of times this is used is to fix a log message, and that
>>> usually happens soon after the commit. It then occurred to me there
>>> are tools like svnsync and svk that use revprops. I think they
>>> usually use revision 0, so that would be a pretty minor special case.
>> We've gone back in our own svn repos and modified very old commit
>> messages, so I wouldn't be too happy if I couldn't modify it.
>> Yet, on the other hand, git doesn't allow any log message modification
>> at all once the commit gets into a public repos as the log message
>> becomes part of the sha1sum, so I don't know how they deal with that.
> IMHO (as a simple SVN user and admin, not developer), allowing changes
> to anything in past revisions is bad practice. Reduces the auditing
> utility of the repository, for one thing. And I guess it could make some
> features more complex and less efficient, like replication. In my repos
> I use a pre-commit hook to disallow commits with empty messages, this
> avoids the most common problem of hitting the 'Commit' button in a GUI
> like Subclipse, forgetting to type the message... for other mistakes
> like typos, the error will just live forever in the history, eternal
> shame on the user, and that's it. Of course this is just my company
> policy but I suspect it's not very uncommon, that's why I made this RFE
> assuming that a partial solution of packing w/o support for posterior
> revprop updates would be a good compromise. Of course, if the SQLite
> solution is both easy and enables more advanced features, that won't
> make me unhappy. ;-)
Well, there's times when people attach the completely wrong log message to a
commit, which would be nice to fix. A typo or other changes could be skipped
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-25 03:05:26 CEST