[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

[Diego Biurrun]

On Sun, Aug 06, 2006 at 09:16:00PM +0200, Michael Niedermayer wrote:
> 
> On Sun, Aug 06, 2006 at 04:26:47PM +0200, Diego Biurrun wrote:
> [...]
> > > > Suppose you wish to remove r12345, just do
> > > > 
> > > >   svnadmin dump --incremental -r 0:12344 REPO > dump_file1
> > > >   svnadmin dump --incremental -r 12346:HEAD REPO > dump_file2
> > > >   svnadmin create new_repo
> > > >   svnadmin load new_repo < dump_file1
> > > >   svnadmin load new_repo < dump_file2
> > > > 
> > > > And this works just as easily if the commit spans 5 directories and 20
> > > > files.
> > > 
> > > a minor nitpick ... i think (though i might be wrong, iam no svn expert)
> > > that you will have to add a dummy 12344->12345 change in the above thing
> > 
> > Not necessary.  The resulting repository will have one revision less of
> > course.  Checkouts can be adversely affected depending on circumstances,
> 
> 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 

In 99% of all cases reverting happens shortly (a few days) after the
commit, so such things are not a problem.  Otherwise all of these things
have to either be changed or a dummy revision added, yes.

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

I meant that 'cvs admin -o' also adversely affects local checkouts and
may require some manual intervention.  That said, if you create a hole
in the revision number all references to that revision also point to a
void...

> > > > > policy said not to copy or move files by remove and add but to ask arpi/root
> > > > > to do it IIRC
> > > > > surely it should mention svn cp/mv now but its not like it wasnt clear about
> > > > > what wasnt allowed
> > > > 
> > > > I think your memory needs a quick freshup:
> > > > 
> > > >   8. Renaming/moving files or contents of files:
> > > > 
> > > >     svn move <source> <destination>
> > > >     svn commit <source> <destination>
> > > > 
> > > >     Do not move or rename files before discussing it on the
> > > >     mplayer-dev-eng mailing list first!
> > > > 
> > > >     Don't do a lot of cut'n'paste from one file to another without a
> > > >     very good reason and discuss it on the mplayer-dev-eng mailing
> > > >     list first. It will make those changes hard to trace.
> > > > 
> > > >     Such actions are useless and treated as cosmetics in 99% of cases,
> > > >     so try to avoid them.
> > > > 
> > > > So maybe this could have been discussed a bit more, but it surely was
> > > > not forbidden.  
> > > 
> > > 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 IMO means: no you cannot move the content of a file
> > > 
> > > did i miss the disscussion of the policy change?
> > 
> > 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

It's a matter of interpretation.  I maintain that it's an editorial and
not a substantial change.  The problem with CVS was that sometimes devs
would remove and readd files, killing the history in the process.  Many
were used to it since CVS simply has no concept of renames so it was a
(sad) fact of life for many.  The text said "cannot", not "must not"...

> and the whole cvs->svn policy chnages change it significnatly,

Ivo volunteered to rewrite the guide, I reviewed his changes, there were
patches and discussion on -dev-eng and -cvslog.  IMO that is more than
plenty occasion to speak up.

I've just looked at the changes again, I really don't see any
significant changes.  We disagree about the interpretation of the
renaming issue, but that only shows that it was ambiguous to begin
with...

> and anyway if its ok to
> 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 ...)
> 
> 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 editorial changes are OK, substantial changes should be discussed on
dev-eng.

Diego