[10:28] <dreamcat4^> hello again! it seems i can't import SVN urls from github? what's up with that?
[10:29] <wgrant> Why can't you do that?
[10:29] <dreamcat4^> i need to use svn (instead of git) b/c submodules in repo's git history, and the new git isn't ready yet.
[10:30] <dreamcat4^> wgrant: it accepts the URL, but the log shows an error msg. this issue has been reported several times.
[10:30] <wgrant> An error message?
[10:30] <dreamcat4^> wgrant: it is: ' INFO No branch found at remote location.'
[10:30] <wgrant> You could also link to the branch.
[10:31] <dreamcat4^> wgrant: http://launchpadlibrarian.net/204306428/dreamcat4-dreamcat4-tvheadend-master.log
[10:31] <dreamcat4^> the branch page is: https://code.launchpad.net/~dreamcat4/dreamcat4-tvheadend/master
[10:33] <dreamcat4^> wgrant: & github svn help page: https://help.github.com/articles/support-for-subversion-clients/
[10:34] <wgrant> Hm
[10:34] <wgrant> It's probably GitHub doing dodgy referer-based routing.
[10:34] <wgrant> Which we can't easily work around.
[10:34] <dreamcat4^> wgrant: ok. be back in a sec.
[10:40] <dreamcat4^> wgrant: ok. well i did offer that explanation back up to #github freenode IRC just now.
[10:41] <dreamcat4^> wgrant: they suggested to try another repo without submodules, but am sceptical. b/c the error msg does not suggest that as the cause.
[10:42] <dreamcat4^> wgrant: your hunch that is hidden behind some ruby / rack redirects seems more likely
[10:42] <wgrant> dreamcat4^: I imagine it's similar to the bitbucket situation, where they only serve git repos to clients with git user-agents.
[10:42] <wgrant> Oh, I said referer earlier, but I meant User-Agent.
[10:50] <dreamcat4^> wgrant: so launchpad can't present itself as a 'svn' user agent, when connecting to github during the svn import ?
[10:51] <wgrant> No.
[10:52] <dreamcat4^> wgrant: hmm.
[10:53] <dreamcat4^> (i look for other possible svn URL of github)
[10:55] <dreamcat4^> wgrant: i try other url now:  https://svn.github.com/tvheadend/tvheadend.git
[10:56] <cjwatson> That doesn't even work with svn co.
[10:57] <dreamcat4^> cjwatson: right. the only URL that work seems to be 'https://github.com/tvheadend/tvheadend'
[10:58] <dreamcat4^> so it seems now more like launchpad aught set it's user agent string properly (if that's possible)
[10:58] <wgrant> Or rather that GitHub shouldn't sniff User-Agent strings.
[10:58] <wgrant> 'cause that's sorta evil.
[10:59] <Spads> everybody set your user-agent to svn now!
[11:00] <dreamcat4^> wgrant: i don't think they are doing anything too terribly evil... if svn client works that way. then it aught to be compatible with svn.
[11:01] <wgrant> Hmm?
[11:01] <wgrant> User-Agent sniffing is unequivocally evil.
[11:04] <dreamcat4^> wgrant: why ?
[11:04] <wgrant> Because it breaks other clients that are otherwise perfectly compatible.
[11:04] <wgrant> eg. bzr-svn
[11:05] <dreamcat4^> it's a program running on their servers. it's necessary b/c svn, git, et all support transport over https now.
[11:05] <dreamcat4^> wgrant: ah right. so it's bzr-svn that's failing then. thanks for mentioning that.
[11:05] <cjwatson> They make entirely different requests over that protocol, though.
=== mattgrif_ is now known as mattgriffin
[14:59] <jelmer> dreamcat4^: this is akin to serving different content to firefox and ie users
[15:54] <dreamcat4^> jelmer: i know. unfortunately that fact doesn't make bzr-svn majically come back from the dead. all i can really do if ask github to provide alternate URL. but there is a big chance they may not provide one.
[15:56] <dreamcat4^> jelmer: but also... it's not quite the same thing the way github uses it
[15:57] <wgrant> SVn and Git make very obviously different requests.
[15:57] <wgrant> You can distinguish the protocol by more than just the User-Agent.
[16:01] <dreamcat4^> wgrant: ok. so if github did either thing, then bzr-svn would work again on github. so they can take their pick.
[16:02] <wgrant> Sure
[16:25] <dreamcat4^> wgrant: but i get an impression they are sending the connections directly to different backends. In which case their code path must decide which backend to sent the new connection to (and not peeking the stream fo first data). That would probably be a lot harder for them to implement.
[16:26] <wgrant> But also a whole lot less wrong!
[16:27] <dreamcat4^> wgrant: well i've just clicked 'submit' on the Github help request form. we shall just have to see what they say about it. (i explained both options).
[16:28] <wgrant> Yep, either one will work.
[16:28] <wgrant> The alternate endpoint is likely easier for them.
=== mattgrif_ is now known as mattgriffin
=== ancoron_ is now known as ancoron