----- Original Message ----
> From: Ryan Schmidt <subversion-2008b_at_ryandesign.com>
> To: Laker Netman <laker_netman_at_yahoo.com>
> Cc: users_at_subversion.tigris.org
> Sent: Wednesday, June 25, 2008 2:12:00 PM
> Subject: Re: Newline in return value from propget, is it a bug?
>
> On Jun 25, 2008, at 1:30 PM, Laker Netman wrote:
>
> > ----- Original Message ----
> >> From: Ryan Schmidt
> >> To: Laker Netman
> >> Cc: users_at_subversion.tigris.org
> >> Sent: Wednesday, June 25, 2008 12:56:38 PM
> >> Subject: Re: Newline in return value from propget, is it a bug?
> >>
> >> On Jun 25, 2008, at 10:30 AM, Laker Netman wrote:
> >>
> >>> I'm running Subversion 1.4.6 and checked the bug tracker under
> >>> "propget", but didn't find anything relevent. I am having an issue
> >>> where testing a value being returned by propget in a post-commit
> >>> perl script always fails. The example below explains what is
> >>> happening.
> >>>
> >>> Here is my test script:
> >>> my $repos = $ARGV[0];
> >>> my $wcLoc = $ARGV[1];
> >>> $wcType = `svn propget wcType svn://repoServer/$repos/$wcLoc`;
> >>> my $updateType = $wcType eq "support" ? "" : $wcLoc eq
> >>> "branches" ? "alpha" : "beta";
> >>> print "WC type=\"$wcType\" and WC location=\"$wcLoc\" therefore
> >>> updateType=\"$updateType\"\n";
> >>>
> >>> Basically, if the repo has a wcType=support then there are no alpha
> >>> or beta directories to deal with during my post-commit process. If
> >>> wcType is something else, or doesn't exist, then based on the
> >>> commit being made to "branches" or "trunk", I have to account for
> >>> "alpha" or "beta" subdirectories (respectively) elsewhere in the
> >>> script.
> >>>
> >>> $repos is the repository name
> >>> $wcLoc is the repository directory where working copy is making the
> >>> commit
> >>>
> >>> When I run this against a repository without wcType set at all this
> >>> is the result (as expected):
> >>> testprop.pl images trunk
> >>> WC type="" and WC location="trunk" therefore updateType="beta"
> >>>
> >>> However, when I run this against a repository with wcType=support
> >>> this is the (incorrect) result:
> >>> testprop.pl images trunk
> >>> WC type="support
> >>> " and WC location="trunk" therefore updateType="beta"
> >>>
> >>> And I expected this:
> >>> testprop.pl images trunk
> >>> WC type="support" and WC location="trunk" therefore updateType=""
> >>>
> >>> But the newline after "support" is messing up the first part of the
> >>> ternary operation.
> >>>
> >>> I know I can fiddle with the string returned by propget, but that
> >>> seems like a workaround. It looks like propget is automatically
> >>> appending a newline to the returned value. When I
> >>> edit the property via TortiseSVNs edit function no newline is
> >>> present,
> >>> however, when I run "svn propget" in a perl script and dump the
> >>> variable to stdout, a newline is definitely present. I created a
> >>> test repository and tried this out with the same result.
> >>>
> >>> So, is this A) a bug, B) by design, or C) caused by something else?
> >>
> >> I can confirm the issue. I'm not sure if it's to be considered a bug.
> >> I guess the newline is meant to make display on a terminal look
> >> better. For example:
> >>
> >>
> >> $ svn pg wcType .
> >> support
> >> $
> >>
> >>
> >> If it didn't output a newline, if would look like this:
> >>
> >>
> >> $ svn pg wcType .
> >> support$
> >>
> >>
> >> As you say, you could work around the problem, e.g. like this:
> >>
> >>
> >> $wcType = `svn propget wcType svn://repoServer/$repos/$wcLoc | xargs
> >> echo -n`;
> >>
> >>
> >> Or if you switched from parsing the command line output to using the
> >> perl language bindings, I'm sure it would provide a cleaner way to
> >> get the property values.
> >
> > Yeah, I can understand from a formatting standpoint it helps, but
> > personally, I would consider it a bug. IMHO, and based on good
> > programming practices related to any function result, the return
> > value from propget should not be adulterated in any way.
>
> Ah, but you're not calling a function. You're calling a command-line
> program which is calling a function and formatting its output for
> you. Like I said, if use use the language bindings instead of calling
> out to the svn command-line program, you should get the unaltered value.
Fair enough. I tend to look at root causes (internal function) versus the surface functionality (command line app). I'll consider the language binding option if I need tighter integration later. A simple "chomp" suffices in this case.
Thanks.
>
> > I'll work around it for now, but I think I'll submit a bug report
> > and see what happens.
> >
> > Thanks for confirming my findings.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-25 21:28:21 CEST