[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

Michael Niedermayer michaelni at gmx.at
Sun Aug 6 21:16:00 CEST 2006


Hi

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


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


> Since Subversion creates diffs
> locally porting changes is easier.
> 
> > > > 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 and the whole cvs->svn
policy chnages change it significnatly, 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" 

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



More information about the MPlayer-cvslog mailing list