people use the "Register branch" form to request code imports

I don't think we're ever going to allow the completely automatic importing of stuff from SVN.

We are working on making the process easier (for you and for us) and more transparent though.

BTW, you shouldn't file an answer ticket for this sort of thing: on the page 'trunk' series for the product you should be able to 'edit source' and put the details there.

There's an interesting aspect in this bug. Some people DO use "Register branch" form to request imports in the past. For example:

 * https://code.launchpad.net/~bluviolin/torapplet/main -> http://svn.berlios.de/svnroot/repos/torapplet/trunk
 * https://code.launchpad.net/~cjcollier/dnpb/cjac -> http://dnpb.svn.sourceforge.net/svnroot/dnpb/branches/Prebuild-cjac
 * https://code.launchpad.net/~mark-baas123/congabonga/trunk -> http://svn.gna.org/viewcvs/congabonga/trunk
 * https://code.launchpad.net/~aquette/nut/nut--trunk -> http://svn.debian.org/wsvn/nut/trunk
 * And more...

I do not think we can sanely fix that until CodeImports are separated from ProductSeries. But even when it's done, I am not sure how we could avoid the confusion.

David Allouche wrote:
> There's an interesting aspect in this bug. Some people DO use "Register
> branch" form to request imports in the past. For example:
>
[...]
>
> I do not think we can sanely fix that until CodeImports are separated
> from ProductSeries. But even when it's done, I am not sure how we could
> avoid the confusion.

Why not just have the one form, and then when the user enters a URL quickly
inspect the URL and figure out if it's a bzr branch or not. If not, walk the
user through the more complex registration for CVS/SVN imports. If it is a bzr
branch, then you're done.

I do not think we'll want the application servers to connect to arbitrary, user specified, servers over the internet.

David, I'm not sure how your comment follows on from Andrew's.

Having one form sounds like a good idea to me.

Marking as 'Incomplete' until we've decided what to do with it.

I think David is objecting to the idea that the lpnet servers should access arbitrary URLs in response to form submissions.

The problem is URLs like "http://example.com/src-repo/my-project/trunk". WIthout accessing the URL or more information from the user, it's ambiguous whether the URL is a Bazaar branch or an SVN branch.

(URLs of the form "svn://..." aren't a problem for this idea, though.)

I do see David's point; we already have systems intended to go hit foreign hosts to mirror/import branches, and they have appropriate reverse DNS so that we show up sensibly in log files, the sysadmins have set the firewalls appropriately, etc.

But if we could accomodate this somehow I think the user experience would be much better. All we'd need to do is a HEAD request on URL + '.bzr/format'. If it exists, it's Bazaar, no more user input needed. If it isn't, prompt the user for more details about SVN import.

We don't have to have the lpnet servers do the actual probing. They could poke another internal system to do it for them, which would deal with the reverse DNS and firewall issues (at the cost of the extra complexity of a new moving part). There's also the question of what to do about unreachable hosts and other timeouts; probably a page saying "sorry we couldn't autodetect, please choose the source control system manually: (*) Bazaar, ( ) Subversion, ..." (we're effectively making them choose manually already after all). Or refuse the registration, because it's probably a mistyped URL, and we can't do anything with it anyway.

It's tempting to guess purely on the string of the URL itself; if it contains the regex "\<svn\>" it's probably an SVN branch, and if not probably not, but we'd need some easy way to override the guess because that won't be 100% reliable. It would have caught all of the examples in comment #2 though. Perhaps a "good enough" solution is to just warn if a Bazaar URL contains "\<svn\>"? Not as elegant for the user as the DWIM of actually probing the URL's location, but perhaps it'd be good enough to deal with most cases?

Fixed in stable r14929 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14929>.