https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6605
--- Comment #11 from Darxus <[email protected]> 2011-05-27 23:26:30 UTC --- (In reply to comment #9) > First, I can't upgrade a production server to use a non-released SVN > unfortunately. So that's a no-go. I wasn't talking about upgrading svn on the server side, I was talking about on the client side - the one where you're running svn diff, and would run svn patch. > When I make the change to $Id$ in sa-update-raw and run svn diff on my devel > machine, svn outputs NOTHING as if the file hasn't even changed. > > On Minotaur, I see this SAME behavior as well so I can't even commit the > change > because SVN doesn't think a change occurred. > > my $VERSION = 'svn' . (split(/\s+/, > '$Id: sa-update.raw 1028810 2010-10-29 15:43:10Z mmartinec $'))[2]; > > So I'm guessing that is expected behavior because svn is sort of hiding this > auto variable handling i.e. svn keywords. Yup. > Fourth, when I change to $Id$ and $LastChangeDate$, etc., I see the > uninitialized errors you are talking about with make test. Yup. > Fifth, the patch doesn't compile due to a missing closing parens in this > logic. > I also changed some small things for consistency and attached a new version. > > + push(@EXTRA_VERSION, > + ('r' . 'unknown'); > + } Sorry, thanks for catching it. > OK, so with that said, the conclusion is that I have made a patch and the > various unitiliazed errors are gone. The trunk passes make test. Awesome. > By my theory and I think your explanation of svn keywords, once I commit this > and run svn update, it should auto expand again... and then if I make, where > versions look like this now: > > sa-update version svnunknown > > SpamAssassin version 3.4.0-rsvnunknown > > They'll change to something like svn<revision>. Yup. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
