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

[Michael Niedermayer]

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

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


>
> With SVN, this is checked by the merge tool, which allows you to rename the 
> old repos into /new/branch. Such a tool would be needed for your system 
> too.

you misunderstood what i was suggesting how cvs/rcs could handle it.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090405/333c87d5/attachment.pgp>