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

[Christian Iversen]

On Tuesday 23 May 2006 11:58, Diego Biurrun wrote:
> 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?

I always "simply" renamed the RCS files on the server, so when I did the 
conversion, the files seemed to have been always called their final name. 
This was to preserve history, of course at the price of not being able to see 
old renaming operations. 

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

Of course. I've been equally stressed, so that wasn't exactly my normal level 
of patience on display there. Let's just forget it :)

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

Of course. I just thought svnserve might be more like CVS pserver, which is 
not correct it seems.

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

Yes, I agree completely. That why I only put password sniffing as a reason. 

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

Well, I don't agree completely there, but then again I set up apache 
configurations for $$ :-)

Also, the subversion extension to apache allows much more fine-grained control 
over user permissions. For instance, you could give a new developer write 
access only to /trunk/somelib for a while, before giving him rw on /trunk. 

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

In my defense, I wrote "fair", not "perfect" ;-)

Many of the advisories in apache seem to stem from the more specialized 
extensions, not from the core server code (at least not any longer). Of 
course, I haven't proved this, so it's not a very convincing argument. It is 
my general impression from reading the security announcements, though. 

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

Allright, fixes that problem of course.

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

Fine by me :)

-- 
Regards,
Christian Iversen