[MPlayer-cvslog] r19258 - trunk/DOCS/tech/oggless-xiph-codecs.txt

Diego Biurrun diego at biurrun.de
Thu Aug 17 12:28:48 CEST 2006


On Thu, Aug 17, 2006 at 11:38:50AM +0200, Michael Niedermayer wrote:
> 
> On Thu, Aug 17, 2006 at 08:48:01AM +0200, Luca Barbato wrote:
> > Michael Niedermayer wrote:
> > > 
> > > the more repositories get split the more problems we will have, as theres
> > > no way to move things from one repo to another, IMHO there never should
> > > have been more then one repository on mphq
> > > so i am against creating yet another repository, also the soc2006 projects
> > > should have been branches of ffmpeg in the ffmpeg repository not seperate
> > > repositories
> > > 
> > 
> > git let you mix and match between repos, I could make some tests with
> > git-svn and see if that way you could get what you want.
> 
> iam not sure what you propose? we cannot do anything about the seperate
> repositories, its a fundamental design limitation of svn that repos cannot
> be merged, having a local git repo of svn will not change anything on that
> or do you propose to switch to git on mphq, that of course is a possibility
> but for that we:
> 1. we would have to look at git and carefully compare it to svn

The problem is why only git?  There seem to be more distributed revision
control systems than there are hairs on a yeti's body.  Off the top of
my head: git, cogito, svk, mercurial, darcs, bazaar, bazaar-ng, arch,
ArX, monotone, codeville, dcvs, libresource, superversion, vesta, plus
bitkeeper and a few more proprietary ones.  There are probably more ..

> 3. we would need to find a server with git for us (could be mphq of 
>    course), this would also solve the security issues with svn no i dont
>    completely agree with our root team about ssh with a "cvs/git/... shell"
>    being a sechole, instead IMHO svn with its homemade crap auth is a sechole
>    (and apache of course would be a giga sechole)

I completely disagree, but let's not get into this discussion again...

Diego



More information about the MPlayer-cvslog mailing list