[MPlayer-cvslog] CVS: main ChangeLog,1.88,1.89

[Diego Biurrun]

On Sat, Aug 06, 2005 at 02:37:31AM +0200, Michael Niedermayer wrote:
> 
> On Saturday 06 August 2005 02:12, Ivo wrote:
> > On Saturday 06 August 2005 02:06, Michael Niedermayer wrote:
> > > hmm, what about commiting this with 'cvs commit -r1.236' ? or am i
> > > missunderstanding the cvs docs?
> >
> > Yes, it seems it's also available for cvs commit.
> >
> > > either way, 1.89 will cause problems for people who have 1.236 currently
> > > i think
> >
> > Maybe, but on my machine those files (Changelog, README...) had no problems
> > going back to 1.88 and 1.16 after the cvs server got back up. What do you
> > suggest, revert and recommit with -r? 
> 
> IMHO yes, but id wait for someone else (alex, rich, ?) to confirm that
> thats a good idea

It's not a good idea and I am strongly opposed to doing it.

Yes, the negative jump in version numbers can cause a hiccup, but no
more than that, it should go away after removing the file in question
and issuing another cvs update.

On the negative side this completely breaks the assumption that revision
numbers should be continuous and you can do things like

cvs diff -r 1.n -r 1.(n-1) filename

and get something meaningful.

> > What about the gap of missing 
> > revisions? Can cvs cope with that?
> 
> AFAIK yes
> and theres also the problem with restoring the lost revissions from
> cvslog, if we do that later then we will have a real mess if we
> "reuse" versions

Should we wish to do that we will have to fix the RCS files with a mix
of manual editing and cvs admin anyway.  "Moving up" revisions will not
really be a further complication in this case.

Furthermore most probably we will just leave the files untouched and
live with the missing history.  Thus with a hole in the revision history
we would only have drawbacks and no advantages.

Diego