[Ffmpeg-devel] CVS --> Subversion conversion, test repository

Diego Biurrun diego
Tue May 23 11:58:23 CEST 2006

On Tue, May 23, 2006 at 01:16:10AM +0200, Christian Iversen wrote:
> On Tuesday 23 May 2006 00:35, Diego Biurrun wrote:
> > On Tue, May 23, 2006 at 12:17:52AM +0200, Christian Iversen wrote:
> > > On Monday 22 May 2006 23:49, Diego Biurrun wrote:
> > > > On Mon, May 22, 2006 at 08:36:14PM +0200, Christian Iversen wrote:
> > > > > On Monday 22 May 2006 17:04, Diego Biurrun wrote:
> > > > > > OK, guys, we're going live real soon now (TM).  I have converted
> > > > > > the CVS repository to Subversion and put a copy of it online.  Get
> > > > > > it via
> > > > > >
> > > > > >   svn checkout svn://www.mplayerhq.hu/ffmpeg_test/trunk/
> > > > >
> > > > > Might I suggest using https:// instead of svn://?
> > > >
> > > > You may not.
> > >
> > > Oh bugger.
> > >
> > > No, seriously, why not? :-)
> >
> > Because you are not a developer
> > and everything you said was wrong or clueless or both.
> > Plus all the technical decisions surrounding the Subversion deployment have
> > already been discussed and are now final.
> > Not to mention that all of the admin team currently has more than enough
> > work without getting into senseless discussions.
> Look, I've just spent over a week doing nothing but CVS conversions and SVN 
> cleanups. I know _exactly_ how tedious and boring the task is.

BTW, did you convert renaming operations?  Did you find a good way to
automate this?

> How about just stating what you just said in a polite manner, instead 
> of assaulting me for making a suggestion?                             
> It's not like I wouldn't understand that your decision is final, and you don't 
> want to dicuss it anymore. However, when your basic argument is "I don't want 
> suggestions, and you're an idiot", I find it hard not to take offense.

OK, I've been slaving away *every* free minute in the last few days on
this transition and it's still not finished.  On top of that I've been
receiving clever comments and suggestions from people who haven't moved
a finger even when directly asked for help.  My patience has been
running very thin lately.  Add a little lack of sleep to the mix and you
get outbursts like the one you just had to suffer from.

However, none of this is your fault and my behavior was indeed uncalled
for.  Please accept my apologies.

Nevertheless all decisions regarding Subversion setup are final.  They
have already been discussed some time ago and I'd like to spend my time
on something more productive than going through the issues once more.

> (I'd still like to know why you think what I said was "clueless or wrong")

I'll run you through the list..

> Advantages:

> - It's encrypted (no password sniffing)

You don't need encryption to avoid password sniffing, there are other
possibilities, like for example challenge-response authentication as
used by svn://.

Our development is - by definition - completely open, so there is little
point in encrypting transferred data.

> - Much, much easier to administer for several users

Why would that be?  svnserve configuration is not complex at all, while
Apache problems can be devilish to debug.

> - Runs on apache, so it's a proven technology with a fair security
>   history.

Apache is proven but surely not secure, just revisit its formidable list
of security advisories.  Besides Apache is huge and complex, which in
itself is a contradiction to being secure.  svnserve on the other hand
is small and does just one thing.  It's been in production use for
enough time to call proven technology as well IMO.

> - Free web-based browsing of all documents in HEAD

Not worth it IMO.  Plus as I stated in my mail, we already set up ViewCVS
to have web-based browsing of the Subversion repositories with all the
bells and whistles, not just HEAD.

> (also, there's no technical reason to use trunk/ - I use projects/
> instead, but anything you can think of is of course possible)

We have one project per repository and trunk/, branches/, tags/ is the
convention, so I'd like to stick to it.


More information about the ffmpeg-devel mailing list