[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Limit 'svn propget --strict' to a single non-recursive target

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 14 Aug 2008 12:20:30 -0400

C. Michael Pilato wrote:
> I've long regretted that, when I added support for --strict to 'svn
> propget', I left the door open for it to be used in recursive propgets
> or otherwise multi-target ones. Why anybody would do this is beyond me,
> because the resulting output is a stream of concatenated byte-for-byte
> property values collected from multiple unidentifiable sources.
> Completely useless for most purposes.
> So, inspired by Julian's work to revamp the propget output, I'd like to
> take this opportunity to undo what I did wrong long ago.
> {{{
> Limit 'svn propget --strict' to a single target. The multi-target
> thing was a mistake resulting often in completely ambiguous output. This
> does *not* change the output at all for the common case, where someone
> is using 'svn propget --strict' to fetch a specific target's value as
> a binary stream sans-beautification.
> * subversion/svn/propget-cmd.c
> (svn_cl__propget): Limit the use of --strict to a single target in a
> non-recursive propget.
> * subversion/svn/main.c
> (svn_cl__cmd_table): Note this limitation.
> }}}
> Yes, this would remove "functionality" (and I use that term
> suspiciously) that exists in the client. That's why I'm not just
> committing it outright -- here's your chance to object on compatability
> grounds, if you wish. But I think this is an improvement worth having.

By the way, I'll be operating under the "silence is assent" model on this.
(Should have said so in the first mail.)

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-08-14 18:20:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.