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

[Michael Niedermayer]

Hi

On Mon, Aug 14, 2006 at 11:12:04AM +0200, Diego Biurrun wrote:
> On Sun, Jul 30, 2006 at 11:41:07PM -0400, Rich Felker wrote:
> > On Mon, Jul 31, 2006 at 02:03:45AM +0200, Michael Niedermayer wrote:
> > > 
> > > On Mon, Jul 31, 2006 at 12:57:55AM +0200, Diego Biurrun wrote:
> > > > On Mon, Jul 31, 2006 at 12:24:56AM +0200, Michael Niedermayer wrote:
> > > > > 
> > > > > On Mon, Jul 31, 2006 at 12:09:45AM +0200, Alex Beregszaszi wrote:
> > > > > > 
> > > > > > > > And while we're at it, why not move nut.txt there, too?
> > > > > > > 
> > > > > > > nut.txt does have a long history and i do mind loosing that
> > > > > > 
> > > > > > Diego said yesterday on IRC that it is possible without history loss.
> > > > > 
> > > > > yes it will randomize revision numbers of the repository tough
> > > > 
> > > > No, it will not, depending on how it's done.  All revisions of nut.txt
> > > > can either be added afterwards with new dates 
> > > 
> > > that will change the revision numbers of nut.txt and it will change the
> > > corresponding dates too
> > > 
> > > > or the repo could also be
> > > > recreated with proper interleaved revisions.
> > > 
> > > which will change the revision numbers of everything including nut.txt,
> > > dates would be correct though
> > > 
> > > personally i dont care enough about the nut repo so feel free to rebuild
> > > it if you like, i do care about correct history (that includes checkin dates)
> > > though
> > 
> > i don't specifically care about them for the nut repo (yet), but in
> > general i think it's bad to recreat the repo with new revision
> > numbers. it makes log mailing list archives useless for looking up
> > revision numbers. personally i find mail folders easier to search than
> > svn but maybe i just don't know how to use svn right...
> 
> So what do you guys want?  I'd like to have an explicit "go" before I
> invest any time in this.
> 
> That said, I'm in favor of separating NUT and MPlayer development, I
> believe it's better for NUT to be considered independent.  Another
> possibility would be to create a separate repository for the
> specification and not maintain it within the libnut repository.

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


> 
> > does svn have a mode like BASIC where it can leave big gaps between
> > revision numbers, maybe? that would solve all our problems... ;)
> 
> Not that I know of.

its probably possible to just do a hundred dummy commits in one of the scripts
which are run after every commit

but i think iam against such a hack ...

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