You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2014/06/09 18:39:10 UTC

--strict vs --no-newline

Summary: I noticed in irregularity, and I plan to tweak the command-line UI a bit to make the '--no-newline' and '--strict' options more consistent.

For a long time we had:

* svnversion --no-newline
Suppresses the newline after the revision number.
Help: "do not output the trailing newline".

* svn propget --strict
Suppresses the newline after the prop val.
Help: "don't print an extra newline".

Originally, 'svn propget --strict' also suppressed the printing of the file name, hence its name being rather general, but in recent years the option is not allowed where more than one result is possible (multiple targets, or depth > empty) nor with --verbose.

With the new-in-1.8(?) '--show-inherited-props' option, 'svn propget --strict' will suppress the newline and the printing of the filename when printing the (multiple) inherited properties for a single target path. That means the property values are all squashed together, and this seems to be a non-useful behaviour, an oversight. I think it should reject the '--strict' option when showing inherited properties, like for the other cases that can produce multiple outputs.

More recently, we gained an 'svn youngest' command, which takes a '--no-newline' option. In r1601362 today, I added the '--no-newline' to 'svnlook youngest', for consistency with the new 'svn youngest'.

Now I intend to:

* make 'svn propget --strict --show-inherited-props' error out;

* make 'svn propget --no-newline' an alias for 'svn propget --strict'.

How to do the latter, exactly? Either make '--strict' an option-name alias for '--no-newline', in which case 'svn youngest --strict' will become an available option; or keep the two options separate and have 'propget' accept both (with the same behaviour) and 'youngest' only accept '--no-newline'. Which is the cleaner UI, the one with fewer invocation options for the user or the one with fewer irregularities?

Thoughts?

- Julian

--
Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise
<http://www.wandisco.com/training/webinars>

AW: --strict vs --no-newline

Posted by Markus Schaber <m....@codesys.com>.

Hi,

Von: Peter Samuelson [mailto:peters@p12n.org]
> [Julian Foad]
> > Do we really want a new subcommand "svn youngest" for this?
> >
> > We already have:
> >
> >   svnversion
> >     # youngest rev in a WC
> >
> >   svn info $URL | grep 'Revision:'
> >     # head revision of repo in which $URL exists
> 
> As Johan has already noted, it's slightly more complicated.  Let me
> add the wrinkle that you also need to make sure LC_MESSAGES is set to
> a known language, as "Revision:" is a localized string.  (My scripts
> tend to say things like:
> 
>     LC_ALL=C svn info $URL | awk '/Revision:/{print $2}'
> 
> You're correct, of course, that a whole subcommand just to get
> information that is already easily available, even if it does require
> awk and an environment variable, seems a bit much.

Don't forget that "svn info" and "svn status" have a "--xml" mode.

Their output is intended to be machine parseable and can be processed (for example using XSLT or xml-coreutils) in an locale-independent way.

Maybe you should have a look into this?


Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

Re: --strict vs --no-newline

Posted by Peter Samuelson <pe...@p12n.org>.

[Julian Foad]
> Do we really want a new subcommand "svn youngest" for this?
> 
> We already have:
> 
>   svnversion
>     # youngest rev in a WC
> 
>   svn info $URL | grep 'Revision:'
>     # head revision of repo in which $URL exists

As Johan has already noted, it's slightly more complicated.  Let me add
the wrinkle that you also need to make sure LC_MESSAGES is set to a
known language, as "Revision:" is a localized string.  (My scripts tend
to say things like:

    LC_ALL=C svn info $URL | awk '/Revision:/{print $2}'

You're correct, of course, that a whole subcommand just to get
information that is already easily available, even if it does require
awk and an environment variable, seems a bit much.

Peter

Re: Don't release 'svn youngest'? [was: --strict vs --no-newline]

Posted by Branko Čibej <br...@wandisco.com>.

On 18.07.2014 20:05, Julian Foad wrote:
> Do we really want to release in 1.9 the 'svn youngest' command that was introduced recently?
>
> There are several kinds of 'youngest' rev we might want to ask for, and we already have the following ways of asking for several of them:
>
>   svn info URL | grep 'Revision:'
>     # head rev of repo
>
>   svn info URL | grep 'Last Changed Rev:'
>     # youngest last-committed rev in subtree at URL (with bubble up)
>
>   svnversion WC_PATH
>     # range of base revs in subtree at WC_PATH
>
>   svnversion --committed WC_PATH
>     # range of last-committed revs in subtree at WC_PATH
>
> while 'svn youngest' only tells us one of them: the youngest rev in the repository.
>
> Can I ask that we use one of these three other UIs instead.
>
> 1.
>
> Add a convenient way to get a single field from 'svn info', as has been proposed several times before.
>
> 2.
>
> Add an 'svnmucc youngest' subcommand instead, since I understand that the primary motivation was for users of 'svnmucc'.
>
> 3.
>
>   svnversion URL
>     # head rev of repo
>
>   svnversion -c URL
>     # range of last-committed revs in subtree at URL
>
> These correspond pretty closely to the existing WC target variants of 'svnversion', and also provide similar information to the two uses of 'svn info URL'.
>
> (Peg revisions should also be supported and should change the meaning to 'the last revision <= peg rev'. And before anybody points out that 'svnversion' has never been linked to RA code, I pre-emptively ask: so what?)

+1 to all of that.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane@wandisco.com

Don't release 'svn youngest'? [was: --strict vs --no-newline]

Posted by Julian Foad <ju...@btopenworld.com>.

Do we really want to release in 1.9 the 'svn youngest' command that was introduced recently?

There are several kinds of 'youngest' rev we might want to ask for, and we already have the following ways of asking for several of them:

  svn info URL | grep 'Revision:'
    # head rev of repo

  svn info URL | grep 'Last Changed Rev:'
    # youngest last-committed rev in subtree at URL (with bubble up)

  svnversion WC_PATH
    # range of base revs in subtree at WC_PATH

  svnversion --committed WC_PATH
    # range of last-committed revs in subtree at WC_PATH

while 'svn youngest' only tells us one of them: the youngest rev in the repository.

Can I ask that we use one of these three other UIs instead.

1.

Add a convenient way to get a single field from 'svn info', as has been proposed several times before.

2.

Add an 'svnmucc youngest' subcommand instead, since I understand that the primary motivation was for users of 'svnmucc'.

3.

  svnversion URL
    # head rev of repo

  svnversion -c URL
    # range of last-committed revs in subtree at URL

These correspond pretty closely to the existing WC target variants of 'svnversion', and also provide similar information to the two uses of 'svn info URL'.

(Peg revisions should also be supported and should change the meaning to 'the last revision <= peg rev'. And before anybody points out that 'svnversion' has never been linked to RA code, I pre-emptively ask: so what?)

- Julian

Julian Foad wrote on 2014-06-17:

> Johan Corveleyn wrote:
>>  Julian Foad wrote:
>>  ...
>>>   Do we really want a new subcommand "svn youngest" for this?
>>> 
>>>   We already have:
>>> 
>>>     svnversion
>>>       # youngest rev in a WC
>>> 
>>>     svn info $URL | grep 'Revision:'
>>>       # head revision of repo in which $URL exists
>> 
>>  Not exactly. It would give you "Revision: 12345", not "12345".
> 
> Yes. The point is, the information is already there...
> 
>>  I think it would be nice if 'svn info' supported a "key" option, so:
>> 
>>      svn info --key Revision $URL
>>      12345
>> 
>>  (or --name, or --whatever).
>> 
>>  Then we'd also have:
>> 
>>      svn info --key "Working Copy Root Path" some/path
>>      C:\MyWorkingCopy
> 
> Yes: without selecting a specific colour to paint this bike shed, I like this 
> kind of interface. The "svn info" UI is already designed to display 
> this kind of information, so let's just make it display it in a more 
> convenient form rather than adding new subcommand for "youngest" and 
> then deciding whether to implement a new subcommand again for each additional 
> bit of info that we might like to access such as repo-UUID, file size, last 
> committed rev, and so on.
> 
> Also: if the primary use case for adding 'svn youngest' was for use in 
> 'svnmucc' work flows, then maybe 'svnmucc' should be providing a 
> 'youngest' command or some other kind of solution to that particular 
> problem-space.
> 
> - Julian
>

Re: --strict vs --no-newline

Posted by Julian Foad <ju...@btopenworld.com>.

Johan Corveleyn wrote:

> Julian Foad wrote:
> ...
>>  Do we really want a new subcommand "svn youngest" for this?
>> 
>>  We already have:
>> 
>>    svnversion
>>      # youngest rev in a WC
>> 
>>    svn info $URL | grep 'Revision:'
>>      # head revision of repo in which $URL exists
> 
> Not exactly. It would give you "Revision: 12345", not "12345".

Yes. The point is, the information is already there, and is accessed through the 'svn info' command.

> I think it would be nice if 'svn info' supported a "key" 
> option, so:
> 
>     svn info --key Revision $URL
>     12345
> 
> (or --name, or --whatever).
> 
> Then we'd also have:
> 
>     svn info --key "Working Copy Root Path" some/path
>     C:\MyWorkingCopy

Yes: without selecting a specific colour to paint this bike shed, I like this kind of interface. The "svn info" UI is already designed to display this kind of information, so let's just make it display it in a more convenient form rather than adding new subcommand for "youngest" and then deciding whether to implement a new subcommand again for each additional bit of info that we might like to access such as repo-UUID, file size, last committed rev, and so on.

Also: if the primary use case for adding 'svn youngest' was for use in 'svnmucc' work flows, then maybe 'svnmucc' should be providing a 'youngest' command or some other kind of solution to that particular problem-space.

- Julian

Re: --strict vs --no-newline

Posted by Johan Corveleyn <jc...@gmail.com>.

On Tue, Jun 17, 2014 at 1:09 PM, Julian Foad <ju...@btopenworld.com> wrote:
...
> Do we really want a new subcommand "svn youngest" for this?
>
> We already have:
>
>   svnversion
>     # youngest rev in a WC
>
>   svn info $URL | grep 'Revision:'
>     # head revision of repo in which $URL exists

Not exactly. It would give you "Revision: 12345", not "12345".

I think it would be nice if 'svn info' supported a "key" option, so:

    svn info --key Revision $URL
    12345

(or --name, or --whatever).

Then we'd also have:

    svn info --key "Working Copy Root Path" some/path
    C:\MyWorkingCopy

Perhaps even have key aliases, and/or multiple keys:

    svn info --key LCR,LCA,LCD $PATH
    5021
    jcorvel
    2014-06-17 13:59:00 +0200

Mmmmmm, just dreaming ...

-- 
Johan