Xavier a écrit :
On Tue, Sep 22, 2009 at 2:09 PM, Dan McGee <dpmcgee@gmail.com> wrote:
Nice, what about my second point? Can we predefine a partial commit message that will need to be edited?
I seemed to get overruled on that one. I know a lot of my commit messages are going to be more worthless than before because I'm just doing a version bump; at least before you got the version info in the commit message.
From what I understood, other people opposed to a default commit message that you don't have to edit. Thomas is proposing to predefine a commit message that still need to be edited. This seems to be the ideal solution, but I don't know if it is possible.
I don't know svn, but reading the doc, this does not seem to be immediately possible. Either you use -m message or -f file and the external editor is not called, or you use them and the editor is called.
I don't know if something like this would work : echo upgpkg: $pkgbase $pkgver-$pkgrel > /tmp/commit-log $EDITOR /tmp/commit-log svn commit -f /tmp/commit-log
Please correct me if I am wrong or if I am missing something :)
Personally I prefer the following approach. 1. When I change anything non-trivial (other than version bumping) in the PKGBUILD, install scriptlet or included files, I do an explicit "svn commit -m 'blabla'" in trunk before running archrelease (usually via commitpkg or one of the symlinks to it). 2. When committing a version bump or simply calling archrelease, there is no need to enforce a commit message other than the default one. The issue is to make sure devs/TUs don't run commitpkg after having made a non-trivial change in trunk. ... Now what about this: modify commitpkg and archrelease so that if the output of $(svn diff) in trunk is not empty, the script will exit with a message saying 'please commit your changes in trunk with svn commit -m "some message"'. I would then remove the whole section with "svn commit" from commitpkg ;) Does that make any sense? If yes I have a patch ready... F