[MPlayer-cvslog] r19839 - in trunk: DOCS/man/en/mplayer.1 DOCS/tech/slave.txt input/input.c libmpcodecs/vf_screenshot.c mplayer.c

The Wanderer inverseparadox at comcast.net
Sat Sep 16 00:11:51 CEST 2006


eugeni wrote:

> Author: eugeni
> Date: Fri Sep 15 15:27:59 2006
> New Revision: 19839
> 
> Modified:
>    trunk/input/input.c
>    trunk/libmpcodecs/vf_screenshot.c
>    trunk/mplayer.c
> 
> Changes in other areas also in this revision:
> Modified:
>    trunk/DOCS/man/en/mplayer.1
>    trunk/DOCS/tech/slave.txt
> 
> Log:
> Add repeated screenshot mode to vf_screenshot.
> It is triggered by "screenshot 1".

Okay, I've been wondering for a while now - how does this happen? I have
two - or actually three, if you count the one on -DOCS - different
commit E-mails with the same revision number and commit messages, but
different listed changes (to different sets of files, to boot). I've
noticed this or variations thereof (I don't remember which) on several
occasions, and still have the relevant mails in my archive if I have any
reason to dig them up.

Is this a misconfiguration of our SVN setup, a bug in Subversion's
commit-notification support, a result of commits somehow being silently
reverted before the second commit goes through (which A: used to happen
when someone used 'cvs admin -o', B: should I think be impossible with
Subversion, and C: seems unlikely anyway since these two commits are
timestamped with the same minute), or something else?

Hmm. I just noticed that I do not, in fact, have a commit mail for
revision 19840 - but I do have one for 19841. Is the second commit
somehow being given the wrong revision number? (If so, how does this
mesh with the fact that the -DOCS commit message also has revision
19839?)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.



More information about the MPlayer-cvslog mailing list