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

[Diego Biurrun]

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.

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

Diego