From: Stephen Bash Date: Wed, 11 Jul 2012 17:49:46 GMT Subject: Re: [PATCH 2/4] Allow reading svn dumps from files via file:// urls. Message-ID: <33a7c123-9db7-4f27-960b-d13db9a71f97@mail> In-Reply-To: <7vbojmfd1u.fsf@alter.siamese.dyndns.org> ----- Original Message ----- > From: "Junio C Hamano" > To: "Dmitry Ivankov" > Cc: git@vger.kernel.org > Sent: Wednesday, July 11, 2012 1:00:29 PM > Subject: Re: [PATCH 2/4] Allow reading svn dumps from files via file:// urls. > > Dmitry Ivankov writes: > > > Florian Achleitner gmail.com> > > writes: > > > > > Especially for testing and development it's useful to bypass > > > svnrdump and replay the svndump from a file without connecting to > > > an svn server. > > > > > > Add support for file:// urls in the remote url. e.g. > > > svn::file:///path/to/dump When the remote helper finds an url > > > starting with file:// it tries to open that file instead of > > > invoking svnrdump. > > > > file:// is a bad choice because file:// style repo urls are valid > > for svn and it's for local repos rather than dumpfiles. > > Thanks; I had the same reaction when I saw it. > > > Maybe something like dumpfile:// instead? > > If dumpfile:// pseudo URL is an established convention in the > Subversion land, that sounds like a sensible direction, but if that is > not the case, it may be cleaner if you can find some other way to > convey the information to the backend out-of-band, instead of > overloading it in the URL used to access the repository. Others may have a different opinion, but in my experience dump files are always handled via stdin/stdout in Subversion land. For example: http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.dump.html http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.load.html http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering I'm not sure that helps in this scenario, but that was the convention I grew used to. Stephen