Nikolaus Demmel <nikolaus@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html