Re: Newline in return value from propget, is it a bug?

2008/6/25 Laker Netman <laker_netman_at_yahoo.com>:
> ---- Original Message ----
>> From: Konstantin Kolinko <knst.kolinko_at_gmail.com>
>> To: Laker Netman <laker_netman_at_yahoo.com>
>> Cc: users_at_subversion.tigris.org
>> Sent: Wednesday, June 25, 2008 1:46:24 PM
>> Subject: Re: Newline in return value from propget, is it a bug?
>>
>> 2008/6/25 Laker Netman :
>> > ----- 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.
>> >
>> > 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.
>
> Yes, and I nearly cited the example of svn:ignore, where newlines can be *explicitly* added.
>
>>
>> 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.
>
> Yes, but if you go into TSVN's property editor, the newline is *not* present.
>
>>
>> I treat such consistency as a very good feature. I can be sure
>> that all the lines of data are interpreted equally and consistently.
>
> I see this as inconsistency, because newlines appear both where I explicitly entered them and where I didn't :)
> If I wanted to make sure I didn't run into the example Ryan used, where the prompt character immediately follows the property value output from propget, then I would be sure to add a newline when entering the property value.
>
> Perhaps a command line argument allowing a user-definable delimiter is the answer? With the default being the current practice, for compatibility.
>
>>
>> Also, "There is also some confusion as to whether newlines
>> terminate or separate lines." (from http://en.wikipedia.org/wiki/End_of_line)
>
> And that's what makes computers so much fun ;-)
>
> Cheers,
> Laker
>

> Yes, but if you go into TSVN's property editor, the newline is *not* present.

It *is* present.
Maybe we are using different versions. Mine is TSVN 1.5.0RC3.

> I see this as inconsistency, because newlines appear both where
> I explicitly entered them and where I didn't :)

There can be different points of view. The mine one is that there is not
a single "multi-line" value, but an ordered list of several
"single-line" values.

Thus the newline is not part of the value, but just a delimiter used
when editing the list.

;)

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 21:21:41 CEST