[MPlayer-cvslog] r19341 - in trunk/stream: Makefile asf_mmst_streaming.c asf_streaming.c network.c network.h pnm.c stream_ftp.c stream_netstream.c stream_rtsp.c stream_vstream.c tcp.c tcp.h

[Uoti Urpala]

On Sun, 2006-08-06 at 21:16 +0200, Michael Niedermayer wrote:
> its not only checkouts but also, externals and any text which refers
> to a specific revision ... IMO a dummy revision must be added if a old
> revision is deleted

I think a dummy revision probably wouldn't be enough to ensure that
existing checkouts continue to work (especially existing checkouts that
are within the changed range). Such repository editing should only be
done if it's absolutely necessary.

> and we might have to delete something one day due to a copyright violation or 
> some private/personal data like phone num / credit card num or such being
> commited

Given that the log list is public and has almost 100 subscribers trying
to censor private data afterwards would likely be too late.

> > but this is no different than CVS. 
> 
> it is, CVS has no problem with holes in the revision numbers, i dunno if
> svn has a problem with it or not ...

CVS certainly didn't handle existing checkout updates well if the
repository was edited directly with cvs admin. And this is mostly
irrelevant IMO since such edits should only occur very rarely if at all.

> > > r18708 said:
> > > ------
> > > 8. Renaming/moving files or content of files, removing empty directories:
> > > 
> > >   You CANNOT do that. Ask the CVS server admin to do it!
> > >   Do NOT remove & readd a file - it will kill the changelog!!!!

> > That's not a policy change IMO, Subversion preserves history so you
> > *can* rename files now without losing history and the rest of the
> > paragraph is unchanged.
> 
> well i disagree, the new text is less strict and the whole cvs->svn
> policy chnages change it significnatly, and anyway if its ok to

What's changed? I read the first line "You CANNOT do that. Ask the CVS
server admin to do it!" of the old policy as a statement of fact: you
cannot do that with the cvs user interface even if you try. Obviously
this claim is simply false now, so dropping it doesn't change anything
about the guideline part. Changing "Do NOT remove & readd a file - it
will kill the changelog!!!!" to "Don't do a lot of cut'n'paste from one
file to another without a very good reason and..." doesn't sound "less
strict" to me - it's phrased with less exclamation marks now, but now
it's against moving large chunks too whereas the old version only talked
about the whole file.

> change the policy like that without disscussions then the policy is
> useless and can be removed as it does not reflect the oppinion of the
> majority of the developers but just the oppinion of one single person
> and maybe not even that as several people can change it at will by
> claiming it doesnt change its meaning (of course they do belive this
> and have no bad intentions, but other developers might disagree ...)

IMO the previous CVS section was outdated; the rationale used to justify
it didn't apply any more. Using such "policy" as the explanation for
some action being wrong isn't a good argument (not that "because it's
policy" would be a good explanation even if the policy made sense -
usually it should be possible to give a proper reason based on the
rationale of the policy).

> so IMO EVERY commit to the policy should be posted as patch to dev-eng
> and should receive at least more "ok" then "not ok" replies, that also
> implies at least one "ok" 

IMO the policy should have no "legal" status as a document that you
"have to" follow, and there should be no formal process to edit it
either. It should just list accepted best practices and give information
that not everyone might know. People who do stupid things can be flamed
whether stupid things are explitly forbidden in the policy or not.