Re: git-svn show-externals and svn version

[Andreas Stricker <astricker@futurelab.ch>]

Nikolaus Demmel <nikolaus@nikolaus-demmel.de> wrote:
> I feel a bit like I am talking to myself, but I see from the high
> traffic on this list that people are busy doing great things :-). I will
> write anyway in case someone interested in git-svn listens.

Um I'm always a bit behind in reading this list. A long time ago my
colleague and I implemented a parser for the new svn:externals format
as a proof of concept[1]. I never took the time to finish it.

> So I've investigated the matter a bit further. Turns out in the
> subversion SWIG language bindings there is an API function that parses
> svn:externals definitions for you.

This looks like a sane approach. I ended with a bunch of complicated
parsing code [2].

> How could this be used in git-svn show-externals? As layed out before, I
> believe that the current output for the svn1.5 syntax is inherently
> broken and we should not worry about backwards compatibility for
> that.

I second that. The output for the new syntax is just plain broken and
can't be used in a sane way. I know that because I tried...

> To maintain backwards compatibility with the output for the old
> format and to give a canonical, easy to parse, output for any external
> definition, I suggest sticking to the current format, just inserting the
> parsed definition at the appropriate place with relative URLs completely
> resolved to absolute ones.

This is exactly what my proof of concept does. The output format keeps
the same as for pre subversion 1.5 format.

> The pre-svn1.5 syntax for external definitions was:
> 
> LOCAL-PATH [-r REVISION] ABSOLUTE-URL
> 
> The output for show-externals was thus (note that there is no parsing of
> the external definition going on yet):
> 
> DIRECTORY-PREFIX/LOCAL-PATH [-rREVISION] ABSOLUTE-URL

Wasn't there also a line commented with a hash "#" before that? Like:
# DIRECTORY-PREFIX

> The DIRECTORY-PREFIX was added because show-externals shows the external
> definitions for all subdirectories recursively. With this prefix, every
> line can be processed on its own. I suggest extending this output to:
> 
> DIRECTORY-PREFIX/LOCAL-PATH [-rREVISION] ABSOLUTE-URL[@PEG-REV]
> 
> Again, as mentioned above, show-externals should parse the definitions
> and resolve relative URLs. Any lines that the svn API call cannot parse
> should be completely ommited (e.g. commented lines and empty lines).

A sane approach. What about a warning about lines skipped?

> As I understand it show-externals is intended primarily for scripts for
> further processing. With this extension existing scripts for the old
> syntax should keep working also long as they don't feature
> peg-revisions. With relative URLs resolved and a standard ordering old
> and new syntax cannot be distinguished in terms of show-externals output
> (except when there are peg-revsion are there).

True. So external tools like git-svn-clone-externals will still work
with this. I verified this with my proof of concept.

Regards, Andy

[1] https://github.com/AndyStricker/git
[2]
https://github.com/AndyStricker/git/commit/9981b3b8313fb831247a16a04d5040bd6a8660b1