[FFmpeg-devel] [RFC] libswscale into the FFmpeg SVN repo

[Christian Iversen]

Michael Niedermayer wrote:
> On Sun, Apr 05, 2009 at 02:36:28AM +0200, Christian Iversen wrote:
>> Michael Niedermayer wrote:
>>> On Sat, Apr 04, 2009 at 10:55:54PM +0200, Diego Biurrun wrote:
>>>> On Sat, Apr 04, 2009 at 10:52:03PM +0200, Michael Niedermayer wrote:
>>>>> On Sat, Apr 04, 2009 at 08:44:51PM +0200, Christian Iversen wrote:
>>>>> [...]
>>>>>>>> I've never used CVS a lot - what kind of support did it have for 
>>>>>>>> moving stuff between reposes?
>>>>>>> you just copy the rcs files on the server, needs an account or someone
>>>>>>> with an account ...
>>>>>>> what was missing was that this didnt keep track of where the file 
>>>>>>> previously
>>>>>>> was ...
>>>>>> Oh, like that. Yes, that was pretty neat. It's still perfectly possible 
>>>>>> with SVN though.
>>>>> only as long as inside the same repo, cvs never had this limitation, a
>>>>> rcs file form one repo can be copied to another like just copying it 
>>>>> within a
>>>>> repo
>>>> And then that file magically appears in checkouts from dates before you
>>>> moved the file, great idea.
>>> Thats what i was speaking about, did you read it at all?
>>> What my "suggestion" was, was that each RCS file would also keep track of 
>>> the
>>> path, not just the file content so past checkouts would not contain the
>>> file in the wrong repo
>>>> Per-file revision control is not a good idea.  What you want to version
>>>> is the whole repository.
>>> thank you, but i know what i want. And the per repo version is why we cant
>>> merge swscale into ffmpeg, with per file we could
>> Well, that's not entirely true. With your system, it would be dangerous to 
>> simply move files into the new repos, because there could suddenly be a 
>> temporal overlap between the files. There could be several files with the 
>> same name at the same time, etc. Therefore, you would still need a special 
>> tool to do this.
> 
> let me repeat it again, it must be darn hard to understand a single
> sentance

Hey, wow. Surely, you not requiring me to read your mind? ;-)

> ->each RCS file would contain the file path<-
> 
> heres a example to show it:
> 
> before the merge:
> file0,v (in mplayer repo)
>     2001-1-1 rev1   cvs.mplayerhq.hu/MPLayer/libswscale/swscale.c
>                     <file content>
>     2002-1-1 rev2   cvs.mplayerhq.hu/MPLayer/libswscale/swscale.c
>                     <other file content>
> 
> file1,v (in ffmpeg repo)
>     2001-2-1 rev1   cvs.ffmpeg.org/ffmpeg/ffmpeg.c
>                     <file content>
>     2002-2-1 rev2   cvs.ffmpeg.org/ffmpeg/ffmpeg.c
>                     <other file content>
> 
> file2,v (in ffmpeg repo)
>     2001-3-1 rev1   cvs.ffmpeg.org/ffmpeg/libswscale extern cvs.mplayerhq.hu/MPLayer/libswscale
> 
> after the merge:
> 
> file0,v (in ffmpeg repo)
>     2001-1-1 rev1   cvs.mplayerhq.hu/MPLayer/libswscale/swscale.c
>                     <file content>
>     2002-1-1 rev2   cvs.mplayerhq.hu/MPLayer/libswscale/swscale.c
>                     <other file content>
>     2009-1-1 rev3   cvs.ffmpeg.org/ffmpeg/libswscale/swscale.c
>                     <other file content>
> 
> file1,v (in ffmpeg repo)
>     2001-2-1 rev1   cvs.ffmpeg.org/ffmpeg/ffmpeg.c
>                     <file content>
>     2002-2-1 rev2   cvs.ffmpeg.org/ffmpeg/ffmpeg.c
>                     <other file content>
> 
> file2,v (in ffmpeg repo)
>     2001-3-1 rev1   cvs.ffmpeg.org/ffmpeg/libswscale extern cvs.mplayerhq.hu/MPLayer/libswscale
>     2009-1-1 rev2   deleted
> 
> a file name conflict cannot happen at or after rev3 check in date because the
> move/copy would have failed due to an existing file at that place.
> and prior to rev3 / 2009-1-1 swscale.c DID NOT exist ANYWHERE in the ffmpeg
> directory structure so it cannot colide either
> 
> I hope what i suggested is clearer now

It is, thanks for the clarification.

However, it hinges on the idea (which you did not tell us about 
initially) that the file path written in the rcs file includes a form of 
repository id (in the form of a path prefix), that allows you to rename 
files into the current repos.

On the other hand, depending on the exact implementation of course, this 
could make it more difficult to simply move a repos to a new server, 
unless you want to keep the old server name in the path prefix.

-- 
Med venlig hilsen
Christian Iversen