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

[Michael Niedermayer]

Hi

On Thu, Aug 17, 2006 at 12:28:48PM +0200, Diego Biurrun wrote:
> 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 ..

propriatary ones / bitkeeper are out of question from what remains git seems
to be mentioned far more often then the others, of course should the others
be considered too if we really want to change the version control system used
and somehow iam not opposed at all to doing that ...

whats important for a version control system is IMHO that it doesnt place 
weird limitations on what can be done
* if i want to move a few files from one
  repository to another then i should be able to do that with all the history
  furthermore checking out old versions should still give identical results
  not like what cvs did when you copied rcs files around
* if i made a typo in a commit message i should be able to fix that, and it
  should be vesioned too ideally so the old message isnt lost
* if i work with several branches then i should be able to merge the not yet
  merged changes from one branch into the other (with or if i choose so
  without history) easily (like svn up) not with a hundread svn merge ;svn ci
* if iam low on diskspace then i should be able to work with a "flat" checkout
  while OTOH if i have a dialup or so connection then i should be able to
  use a complete copy of the repository locally



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

agree, the whole is far too hypothetical ATM to flame about it now
and iam aware that the admin team probably is unanimously against ssh
based stuff

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is