2008/6/25 Laker Netman <laker_netman_at_yahoo.com>:
> ----- 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 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.
>
> 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.
>
> Laker
>
IMHO, it is not a bug.
Please note, that property values often have several lines
of data, especially svn:externals and svn:ignore ones.
In TortoiseSVN, when I query values of those properties, there is
always a new line at the end of the text, regardless of
whether it was there when I set those values.
I treat such consistency as a very good feature. I can be sure
that all the lines of data are interpreted equally and consistently.
Also, "There is also some confusion as to whether newlines
terminate or separate lines." (from http://en.wikipedia.org/wiki/End_of_line)
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
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 20:46:48 CEST