[FFmpeg-soc] E-AC3 decoder, version control

[Justin Ruggles]

Michael Niedermayer wrote:
> On Sun, Dec 09, 2007 at 12:54:13PM -0500, Justin Ruggles wrote:
>> Hi,
>>
>> I've decided to go ahead and clean up the E-AC3 decoder so it can be 
>> included in FFmpeg.  One thing that's giving me a hard time getting 
>> started is that there are copies of files that are already in FFmpeg, 
>> but an old snapshot, plus changes.  What a mess.  
>> What I really want to 
>> do, if it's okay, is to wrap all the changes to existing files into the 
>> ffmpeg.patch.  The history of changes to existing code won't be saved, 
>> but trying to preserve them on top of changes that have been made in 
>> subsequent revisions would be a nightmare.  This is a time that I really 
>> wish soc was a group of git branches. :) Maybe next year...
> 
> i dont think messing up will be avoided by using a different VCS
> its the users (developers here) who mess up not the tools they use
> 
> that said, if you have a server with enough bandwidth, where we can host
> soc git repos for next year with accounts for all ffmpeg devels, and a
> admin who reacts to project management requests properly
> then i see no problem

I agree. It can be done correctly with the tools we have, if done 
carefully.  I don't have a server, just wishful thinking.

> 
>> I guess another option would be to go back and "rebase" by manually 
>> applying each change since the snapshot and resolving any conflicts. 
>> That's pretty labor-intensive though, and it still doesn't make things 
>> any easier when it comes time to merge into FFmpeg SVN since I can't go 
>> back and insert the changes at the beginning.  I would sort of have to 
>> recreate the file histories, resolving each conflict one at a time, on 
>> top of the current versions. Yikes.
>>
>> Any thoughts?
> 
> i really have lost track of all the changes in public and non public branches
> and repos of the ac3 code and cant comment on vague changes i dont see
> please use the words ffmpeg-svn soc-svn private-git? and revission numbers
> if possible. so i can take a look at what you are speaking about

Sorry, what I'm getting at is that what is in soc-svn is a mix of new 
files and files which are already in ffmpeg-svn.  The duplicated files 
in soc-svn were taken as a snapshot at r10002, then modified, but are 
not current, by about 10 commits or so.

> and what i can say is that what will be applied to ffmpeg-svn will have to
> pass reveiw and smaller and clean patches will be significantly less
> work for all involved

Indeed.

> iam not insisting on the true history from soc if its difficult to preserve

Great, then the changes to existing files can be split into logical 
patches for inclusion rather than trying to keep their histories from 
soc-svn.  The new files will, of course, have their soc histories in 
tact.  I'll go ahead and update the files in soc-svn to current 
ffmpeg-svn, then keep up-to-date with any future changes.

Thanks,
Justin