Request: Changing commit message in llvm trunk

Hi

I’m trying to change a commit message that became malformed when pushing to trunk

svn propedit svn:log --revprop -r 243434
svn: E175002: DAV request failed; it’s possible that the repository’s pre-revprop-change hook either failed or is non-existent
svn: E175002: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook

As described here commit messages are not versioned on svn

Would it be possible to get a hook made for this
http://stackoverflow.com/questions/692851/can-i-go-back-and-edit-comments-on-an-svn-checkin

It could be very useful for 3 reason.

Currently if someone makes a commit and does not have it is not automatically closed by phabracator by adding
Differential Revision: http://reviews.llvm.org/DXXXXX

at the end of their commit

The committer then often has to go back and manually enter a message to tell someone that their patch has landed

With a hook for this it would be easy to update the message invoking phabracator to now close the revision as it has landed.

we could even quite easily create a script for this for any committer to use to speed up the process, example here is a script called landed

landed D11511 r243434

If a patch is reverted at some point because it is broken.

It would be nice to be able to edit the commit message in rXXX to tell the reader that the commit was reverted in rYYY and reapplied with a fix in rZZZ

If you have a pesky typo in your commit like I have :slight_smile:

I’m sure the hook could be made so that only an author can edit their own commit message or an admin that can.

Kind Regards

Martell

It could be very useful for 3 reason.

This will surely break git mirrors.

Anton Korobeynikov wrote:

It could be very useful for 3 reason.

This will surely break git mirrors.

Sounds like the git mirror's problem.

This will surely break git mirrors.

Sounds like the git mirror's problem.

And every user of those mirrors, unless we have the resources to forge
a SHA1 hash for the new commit message.

Tim.

I don't think the git mirror would be *terribly* broken, it'd just never see the commit message change. But, the annoying part would be if/when someone recreated the git mirror, as it would then contain the new commit message, and thus that commit and all subsequent commits would have a different commit-hash.

This will similarly "break" anyone's svn mirrors (e.g. done by svnsync), as it cannot automatically detect that a commit message has been updated. If you were paying attention, you could copy the new data via svnsync copy-revprops, but that basically requires manual interaction.

Independently of those particular breakages, it's just a terrible idea to allow unversioned modifications to be made to the version control's historical record. That's the kind of thing that should only ever be done in truly exceptional cases by a repository admin.

-1 to ever enabling revprop changes.

This will surely break git mirrors.

Sounds like the git mirror's problem.

And every user of those mirrors, unless we have the resources to forge
a SHA1 hash for the new commit message.

Caveat: I'm not a git expert, but we could export the changed svn
commit message as a "note" to the corresponding git commit.

Hi

I'm trying to change a commit message that became malformed when pushing
to trunk

svn propedit svn:log --revprop -r 243434

svn: E175002: DAV request failed; it's possible that the repository's
pre-revprop-change hook either failed or is non-existent
svn: E175002: Repository has not been enabled to accept revision
propchanges;
ask the administrator to create a pre-revprop-change hook

As described here commit messages are not versioned on svn
Would it be possible to get a hook made for this

tortoisesvn - Can I go back and edit comments on an SVN checkin? - Stack Overflow
<tortoisesvn - Can I go back and edit comments on an SVN checkin? - Stack Overflow;

It could be very useful for 3 reason.

1.
Currently if someone makes a commit and does not have it is not
automatically closed by phabracator by adding
Differential Revision: http://reviews.llvm.org/DXXXXX
<https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11511&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=rA66OwhKyNgAo35v-7-yD5YmsmgWkfGpODyqFgA-Sug&s=MO-ifc5cGb5v_ThESxcVSdiZCzBphnRq2W57Z6Wgd1M&e=&gt;
at the end of their commit
The committer then often has to go back and manually enter a message to
tell someone that their patch has landed

With a hook for this it would be easy to update the message invoking
phabracator to now close the revision as it has landed.

we could even quite easily create a script for this for any committer to
use to speed up the process, example here is a script called landed

landed D11511 r243434

Probably easier to have Phab just monitor the post-commit review thread on
the mailing list.

2.
If a patch is reverted at some point because it is broken.
It would be nice to be able to edit the commit message in rXXX to tell the
reader that the commit was reverted in rYYY and reapplied with a fix in rZZZ

Usually we chime in on the post-commit thread saying "btw, reverted in
rXXXXXX".

3.
If you have a pesky typo in your commit like I have :slight_smile:

I don't think anybody really cares very much about typos in the commit
history, as long as they are clarified in the post-commit thread (just like
if the code has a problem or whatever).

-- Sean Silva

Thanks for all the feedback guys

So rather than speculating about what could and might not break.

I am going to test all these different scenarios by creating my own svn server, svn mirror and git mirror etc
I’ll get back to you all with details on what breaks and what doesn’t soon with changing the commit msgs

Many Thanks
Martell

Even if you do discover some way to make git-svn mirrors support updates to
past commit messages, I'm not sure we'd want to use it. I think most people
would rather keep the history simple.

People make bad commits to LLVM all the time, and there's nothing wrong
with that. The normal way we deal with it is to revert the change and
commit it again with a fix. Bad commit messages aren't really that
different from bad code, and they can be fixed the same way. :slight_smile:

Just a thought, and I’m sure this has been discussed before, but what about hosting on github?

GitHub provides an excellent svn bridge for people who still want to use svn.

We host a number of projects on github where we have a few devs who are more comfortable using an svn client and it seems to work very well.