You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2002/09/06 16:31:39 UTC
RFC: Newline conversion in log messages and special props
Hi all,
I'd like some feedback on the following proposal that would fix
usability and interop problems with "svn commit" and "svn propedit" on
non-Unix clients.
The problem is that many Windows editors -- notably the ubiquitous
Notepad -- don't play nicely with files with lines ending in anything
but CRLF. When "svn commit" starts the editor, the default message is
unreadable, because it only contains LFs. Now, while teaching svn to
generate correct line endings in the default text is quite easy, the sad
result is that you then get CRLFs in the log messages in the repository.
Since we take such pains convert the log messages to UTF-8, it seems a
bit inconsistent to allow mixed line endings.
Proposal: When converting log messages to UTF-8, also convert line
endings to LF. Conversely, when converting log messages to the
locale encoding (for $EDITOR or for display purposes), also convert
line endings to the native form.
I think some of the special properties should get similar treatment:
* Line-based textual properties: svn:ignore, svn:externals
* Whitespace-separated textual properties: svn:keywords
While we're at it, perhaps we should also strip all whitespace from
keyword-like properties: svn:eol-style and svn:mime-type. I seem to
recall that we already had problem reports because a newline found its
way into svn:mime-type.
I think that leaves svn:executable, which I don't care about so much. It
might make sense to only allow empty contents on that prop since it's a
boolean -- only its existence matters, not the contents -- but that's
more an aesthetic than a usability issue.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Branko Čibej wrote:
> Proposal: When converting log messages to UTF-8, also convert line
> endings to LF. Conversely, when converting log messages to the
> locale encoding (for $EDITOR or for display purposes), also convert
> line endings to the native form.
>
> I think some of the special properties should get similar treatment:
>
> * Line-based textual properties: svn:ignore, svn:externals
> * Whitespace-separated textual properties: svn:keywords
+1 this seems like the best way to handle this problem.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Yeah, good points.
Hmmm. I dunno. Personally, I think I'm gonna punt on this one for
now, as there are more pressing matters before us anyway. Maybe
someone will think of an elegant solution, though.
-K
Nicholas Riley <nj...@uiuc.edu> writes:
> - It blurs the distinction between options and commands to an extent
> that I think will ultimately be confusing. It's great that svn
> doesn't have the stupid 'do I put it before or after the command?'
> distinction that cvs uses. Someone seeing, for example, 'svn -R -x'
> in a shell script will become confused. Would you allow 'svn -Rx' for
> that matter?
>
> - It's non-extensible. It is just a matter of time before people will
> ask for this kind of shorthand to apply to lots of file metadata that
> is ultimately mapped to properties in the repository - permissions,
> attributes, file flags, etc. It'd make sense for each of these to
> emulate the corresponding commands - svn chmod, svn chattr, svn
> chflags, etc., so why not do it that way from the start?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Nicholas Riley <nj...@uiuc.edu>.
On Fri, Sep 06, 2002 at 01:01:21PM -0500, Karl Fogel wrote:
> "Bill Tutt" <ra...@lyra.org> writes:
> > Alternatively, "svn +x <WCTarget>"/"svn -x <WCTarget>" would also do the
> > trick.
> >
> > If the interface gets awkward, it usually means you need to examine if
> > you're using the wrong interface. ;)
>
> Hey! I really like the +x / -x idea.
Me too, but in that context I can think of two problems:
- It blurs the distinction between options and commands to an extent
that I think will ultimately be confusing. It's great that svn
doesn't have the stupid 'do I put it before or after the command?'
distinction that cvs uses. Someone seeing, for example, 'svn -R -x'
in a shell script will become confused. Would you allow 'svn -Rx' for
that matter?
- It's non-extensible. It is just a matter of time before people will
ask for this kind of shorthand to apply to lots of file metadata that
is ultimately mapped to properties in the repository - permissions,
attributes, file flags, etc. It'd make sense for each of these to
emulate the corresponding commands - svn chmod, svn chattr, svn
chflags, etc., so why not do it that way from the start?
--
=Nicholas Riley <nj...@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> That's horrible, but luckily you both misunderstood. :-)
I agree, it was horrible. I don't know what got into me :-).
> What I meant is that _any_ value supplied for svn:executable would be
> simply discarded, not that you'd only be allowed to set it to an empty
> value. That's just another bit of prop-specific post processing.
+1
In that case, we should probably guard against values of "no", "off",
"nil", "nada", etc, in various languages.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>"Bill Tutt" <ra...@lyra.org> writes:
>
>
>>Alternatively, "svn +x <WCTarget>"/"svn -x <WCTarget>" would also do the
>>trick.
>>
>>If the interface gets awkward, it usually means you need to examine if
>>you're using the wrong interface. ;)
>>
>>
>
>Hey! I really like the +x / -x idea.
>
>We're currently using 'x' as the "extension" option, for passing args
>to subprocesses like diff. We could change that to 'X', to free up
>'x' for executable, though.
>
That's horrible, but luckily you both misunderstood. :-)
What I meant is that _any_ value supplied for svn:executable would be
simply discarded, not that you'd only be allowed to set it to an empty
value. That's just another bit of prop-specific post processing.
Anyway, it's just a minor nit. I'll create an issue about the other
ideas, seeing as there were no objections.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"Bill Tutt" <ra...@lyra.org> writes:
> Alternatively, "svn +x <WCTarget>"/"svn -x <WCTarget>" would also do the
> trick.
>
> If the interface gets awkward, it usually means you need to examine if
> you're using the wrong interface. ;)
Hey! I really like the +x / -x idea.
We're currently using 'x' as the "extension" option, for passing args
to subprocesses like diff. We could change that to 'X', to free up
'x' for executable, though.
(Does APR getopt parsing allow us to distinguish between an option
passed with + and the same one passed with -, though?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: RFC: Newline conversion in log messages and special props
Posted by Bill Tutt <ra...@lyra.org>.
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> Branko Čibej <br...@xbc.nu> writes:
> > Proposal: When converting log messages to UTF-8, also convert
line
> > endings to LF. Conversely, when converting log messages to the
> > locale encoding (for $EDITOR or for display purposes), also
convert
> > line endings to the native form.
> >
> > I think some of the special properties should get similar treatment:
> >
> > * Line-based textual properties: svn:ignore, svn:externals
> > * Whitespace-separated textual properties: svn:keywords
> >
> > While we're at it, perhaps we should also strip all whitespace from
> > keyword-like properties: svn:eol-style and svn:mime-type. I seem to
> > recall that we already had problem reports because a newline found
its
> > way into svn:mime-type.
>
> +1 on all of this.
>
Ditto.
> > I think that leaves svn:executable, which I don't care about so
> > much. It might make sense to only allow empty contents on that prop
> > since it's a boolean -- only its existence matters, not the contents
> > -- but that's more an aesthetic than a usability issue.
>
Handle it as a special case in the argument handling phase for "svn
propset".
svn:executable is a Subversion owned property.
I don't suppose you'll fall for that though.
Alternatively, "svn +x <WCTarget>"/"svn -x <WCTarget>" would also do the
trick.
If the interface gets awkward, it usually means you need to examine if
you're using the wrong interface. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Newline conversion in log messages and special props
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Proposal: When converting log messages to UTF-8, also convert line
> endings to LF. Conversely, when converting log messages to the
> locale encoding (for $EDITOR or for display purposes), also convert
> line endings to the native form.
>
> I think some of the special properties should get similar treatment:
>
> * Line-based textual properties: svn:ignore, svn:externals
> * Whitespace-separated textual properties: svn:keywords
>
> While we're at it, perhaps we should also strip all whitespace from
> keyword-like properties: svn:eol-style and svn:mime-type. I seem to
> recall that we already had problem reports because a newline found its
> way into svn:mime-type.
+1 on all of this.
> I think that leaves svn:executable, which I don't care about so
> much. It might make sense to only allow empty contents on that prop
> since it's a boolean -- only its existence matters, not the contents
> -- but that's more an aesthetic than a usability issue.
Hmmm. It's awkward for people to actually set empty contents -- in
many environments, they'll be forced to use quotes. Aesthetically and
intuitively, the first of these seems much better to me:
svn propset svn:executable on foo.sh
versus
svn propset svn:executable '' foo.sh
Although that does leave the possibility of someone trying
svn propset svn:executable off foo.sh
and being surprised when the file is still executable :-(. Not sure
what to do about that. We could check for counter-intuitive values,
but even then we'd never get all languages, just English and whatever
else some developer happened to take care of.
If we're going to allow just one value at propset time, rejecting all
others, maybe we should just go with English "on", and continue to
treat any non-null value as we do now? At least not the empty string,
that's going to be something people have to look up all the time.
Thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org