Re: [PATCH 1/5] Add a generic tree traversal to fetch SVN properties.

[Eric Wong <normalperson@yhbt.net>]

Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> On Oct 16, 2007, at 9:43 AM, Eric Wong wrote:
> 
> >Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> >>	* git-svn.perl (&traverse_ignore): Remove.
> >>	(&prop_walk): New.
> >>	(&cmd_show_ignore): Use prop_walk.
> >>
> >>Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
> >
> >Although I myself have never needed this functionality, this series
> >looks pretty good in general.
> 
> I heavily script Git with my own wrappers and having this sort if  
> functionality does enhance the scriptability of git-svn.

Ah.  I've actually wanted something like `svn info` or `git-svn
rev-parse` myself for a while, but haven't gotten to implementing it
myself, either.  Something that could easily give me the current URL of
a repo, or the URL of any path in a repo

	$ git svn info --remote-url local/path.c
	=> https://example.com/svn/trunk/local/path.c

	$ git svn info --url
	=> https://example.com/svn/trunk

I think there was other functionality that I've wanted in the past
but have forgotten at the moment.  I need to sleep, badly :x

> >Thanks.
> 
> You're welcome :)
> 
> >
> >One comment below about property selection (whitelist vs blacklist).
> >
> >
> >It would be possible to get identical information out of  
> >unhandled.log,
> >but older repositories may not have complete information...  Maybe  
> >some
> >local option would be good for people with complete unhandled.log  
> >files;
> >but it could be really incomplete/insufficient.
> >
> 
> In order to avoid using SVN::Ra and avoid access to the SVN repo?   
> Hmm, clever, I didn't think about this.  Maybe we can provide both,  
> the default would check unhandled.log and an option would enable  
> direct access to the SVN repo?

Yes.  I'm alright with the direct SVN repo code for now, and we can do
unhandled.log later since it's more things to do.

> >Coding style
> >
> >Other than that, I prefer to keep braces on the same line as foreach,
> >if, else statements.  I generally follow the git and Linux coding
> >style for C in my Perl code.
> >
> >One exception that I make for Perl (but not C) is that I keep the "{"
> >for subs on the same line (since subs can be nested and anonymous ones
> >passed as arguments and such); unlike their C counterparts[1]
> 
> Indeed, sorry, I started correctly but then completely forgot to  
> follow the existing Coding Style.  The CS I use daily is totally  
> different, sorry ;)
> Shall I resend the patch series with corrected CS?

Yes, please.  Thanks.

-- 
Eric Wong