Jan Hauke Rahm wrote: >> E.g. when checking out r8614 (making BASE=8614) then commiting changes >> that become r8615 (BASE is still 8614!!!) then tagging with >> svn-buildpackage which does a "-rBASE cp . svn://.." r8614 will be >> tagged instead of r8615! > > That is true but I think it's the user's responsibility to keep his > working directory up to date.
The working directory IS up-to-date. The BASE revision just doesn't reflect the revision of the working directory after a commit. This might be a problem with SVN itself - I'm not sure - the documentation doesn't seem to say anything about BASE beeing updated on a commit. It obviously doesn't do so: mkdir /tmp/svn svnadmin create /tmp/svn svn mkdir -m"init" file:///tmp/svn/trunk file:///tmp/svn/tags svn co file:///tmp/svn/trunk workingdir cd workingdir svn info . # BASE-Revision at this point is 1 touch a svn add a svn ci -m"test" svn info . # BASE-Revision at this point is still 1, even if the working # directory is technically at revision 2 now !!! svn up . svn info . # Now we have BASE=r2 >> To fix the problem, I suggest to remove "-rBASE" from the tagging commands. >> Please see the attached patch. > > Actually, that was introduced in the recent upload exactly to achieve > what you want to avoid here. svn-buildpackage should not try to tag > anything but what the user checked out. But that's exactly what is happening now. It sets the tag to a different revision as the one I have in my working directory. As it is right now, I believe it's a big problem. I ran --svn-tag on 3 packages until I noticed, that svn-buildpackage tags the wrong version. I'm pretty sure, that a lot of other maintainers will fall into the same trap - and what's even worse, probably will not notice, that the tagging went wrong. The usual workflow with svn-buildpackage is (at least for me) e.g.: - svn-upgrade .. - update debian/* as required - debcommit - svn-buildpackage - svn-buildpackage --svn-tag And this will lead to a tag pointing to the wrong revision. > Before 0.8.0 it tagged HEAD, > i.e. the remote state, which was bad, too. I guess having to choose here > is how subversion was designed. Ok, you are right, that tagging HEAD might be wrong too. But if you drop the "-rBASE" from the tagging command, it will still tag the revision of the local working directory instead of HEAD. Continuing my example from above: cd .. svn co -r1 file:///tmp/svn/trunk revision1 cd revision1 # We are now in a working copy that is != HEAD svn cp -m"tagging" . file:///tmp/svn/tags/a_tag # We've now tagged revision1, and not HEAD! As you see - you can drop -rBASE and it will still do what you want - tag the checked out working dir, not HEAD. > As a consequence I consider this bug won't-fix. Please reconsider this decision. The current behaviour is harmful, because if you don't do an svn-update after commiting changes you will tag the wrong version and probably won't even notice it until someone checks out the tag. Tobias
signature.asc
Description: OpenPGP digital signature
