[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/...

[Måns Rullgård]

Alex Converse <alex.converse at gmail.com> writes:

> 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.

I did and didn't find anything.

> Libswscale living by it self is also a huge pain in the ass in the

That is the other major obstacle preventing a switch-over.

Besides, libswscale being separate is a huge PITA in svn too.  SVN
externals was a stupid idea, just like so many other thing in that
sorry excuse for a VCS.

-- 
M?ns Rullg?rd
mans at mansr.com