---- 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
---------------------------------------------------------------------
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:59:48 CEST