[FFmpeg-cvslog] r22522 - in trunk: configure libavcodec/Makefile libavcodec/dsputil.c libavcodec/dsputil.h libavcodec/dwt.c libavcodec/dwt.h libavcodec/ivi_dsp.c libavcodec/snow.c libavcodec/snow.h libavcodec/x86/...
Alex Converse
alex.converse
Sun Mar 14 21:33:09 CET 2010
2010/3/14 M?ns Rullg?rd <mans at mansr.com>:
> Alex Converse <alex.converse at gmail.com> writes:
>
>> 2010/3/14 M?ns Rullg?rd <mans at mansr.com>:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>
>>> R> On Sun, Mar 14, 2010 at 07:38:38PM +0000, M?ns Rullg?rd wrote:
>>>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>>>
>>>>> > On Sun, Mar 14, 2010 at 06:50:12PM +0100, mru wrote:
>>>>> >> Author: mru
>>>>> >> Date: Sun Mar 14 18:50:12 2010
>>>>> >> New Revision: 22522
>>>>> >>
>>>>> >> Log:
>>>>> >> Separate DWT from snow and dsputil
>>>>> >>
>>>>> >> This moves the DWT functions from snow.c and dsputil.c to a file of
>>>>> >> their own. ?A new struct, DWTContext, holds the function pointers
>>>>> >> previously part of DSPContext.
>>>>> >>
>>>>> >> Added:
>>>>> >> ? ?trunk/libavcodec/dwt.c
>>>>> >> ? ?trunk/libavcodec/dwt.h
>>>>> >> ? ? ? - copied, changed from r22521, trunk/libavcodec/snow.h
>>>>> >
>>>>> > is dwt.c not missing a svn cp?
>>>>>
>>>>> It's only a tiny part of snow.c, the diff would be enormous. ?Besides,
>>>>> git blame has no trouble tracking the origin of the code.
>>>>
>>>> we are using svn for trunk, it would thus be nice if svn metadata would
>>>> stay correct.
>>>> and gits tracking is guessing, svn stores the true origin.
>>>
>>> Nevertheless git blame give much more details, and correct,
>>> information. ?You should try it some time.
>>
>> Now that git-notes seem like a relatively mature way to annotate
>> commit messages perhaps it's time to revisit transitioning to git.
>
> I'd prefer to have more people start using git-svn first.
>
The current git-svn setup is somewhat lacking IMHO.
We still can't dcommit from the official git mirror. With everyone
git-svn cloning separately to be able to dcommit, it makes it
difficult to share work due to amended commit messages (for instance
trying to pull your AAC tree into my tree was problematic). You said
you were going to look into this. Libswscale living by it self is also
a huge pain in the ass in the in the current git-svn set up. It makes
it difficult to bisect for regression tracking and to switch to old
branches on the fly.
--Alex
More information about the ffmpeg-cvslog
mailing list