You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Olleg Samoylov <ol...@mipt.ru> on 2006/02/17 14:57:02 UTC
patch newline in log messages
Sometimes newline exits at the end of log messages. Sometimes not. This
is patch "svn log" to check of trailing newline and put newline at the
end only if it's needed.
--
Olleg Samoylov
Re: patch newline in log messages
Posted by kf...@collab.net.
Julian Foad <ju...@btopenworld.com> writes:
> OK, so Karl doesn't want his trailing newlines removed. Greg's quote
> is a conditional suggestion ("we would ...") out of context so it
> doesn't mean much by itself. These are only the opinions of certain
> people at a certain time, and don't necessarily mean that we will or
> won't do anything in particular.
I agree with what Julian says above. My opinion is just one
developer's opinion, even if it's a strong opinion. The developer
group could override it.
However, I do think Greg Hudson has the right idea: in the end, we
should treat log messages as a series of lines, and enforce the
convention that every line (including the last one) ends with a
newline.
> For example, if the problem is that you want consistent spacing at the
> end of each log message in your own repositories, here is one solution
> that may be acceptable to you and doesn't require changing Subversion
> at all: fix up all the old log messages, and write a pre-commit hook
> script that trims off or normalises any trailing newline(s) in the log
> message about to be committed.
+1 It's very easy to enforce whatever convention you want by using a
hook.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by kf...@collab.net.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> Yikes. Until you explained it to me on IRC, I had no clue what it's doing.
> (It's attempting to ensure that we always catch every revision while the
> script is running.)
>
> However, the only real way to prevent this is to install the pre-commit hook
> and then run the all-revs version of it. If you did the reverse, there's
> always a race condition that you'd miss some revisions - in between the time
> you ran all-revs and installed the pre-commit hook.
>
> So, it should be something like:
>
> elif all_revs:
> for this_rev in range(0, svn.fs.svn_fs_youngest_rev(fs) + 1):
> fix_up_rev(fs, this_rev)
>
> It's also much shorter and easier to understand too. ;-) -- justin
:-)
As per later IRC discussion, I'll put a comment there explaining
what's going on. I do like being as bulletproof as possible (if
that's a meaningful concept), although you're right about the race
condition still being there if the admin does things in the wrong
order.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 03 Mar 2006 11:32:02 -0600, kfogel@collab.net <kf...@collab.net> wrote:
>
> elif all_revs:
> last_youngest = 0
> while True:
> youngest = svn.fs.svn_fs_youngest_rev(fs)
> if youngest >= last_youngest:
> for this_rev in range(last_youngest, youngest + 1):
> fix_up_rev(fs, this_rev)
> last_youngest = youngest + 1
> else:
> break
Yikes. Until you explained it to me on IRC, I had no clue what it's doing.
(It's attempting to ensure that we always catch every revision while the
script is running.)
However, the only real way to prevent this is to install the pre-commit hook
and then run the all-revs version of it. If you did the reverse, there's
always a race condition that you'd miss some revisions - in between the time
you ran all-revs and installed the pre-commit hook.
So, it should be something like:
elif all_revs:
for this_rev in range(0, svn.fs.svn_fs_youngest_rev(fs) + 1):
fix_up_rev(fs, this_rev)
It's also much shorter and easier to understand too. ;-) -- justin
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Michael Brouwer <mb...@gmail.com>.
(Resending this since I acidentally forgot to CC the list)
The only reason I'd suggest keeping the last newline rather than
removing it is that some editors (like the default vi on most systems)
always turn the last line into a newline, so if you did a propedit on
the log message of a revprop a newline would get appended. Of course
if you made sure that even after a propedit that newline was removed,
that would work as well.
Michael
On 3/6/06, Molle Bestefich <mo...@gmail.com> wrote:
> kfogel@collab.net wrote:
> > THE PROPOSAL:
> > -------------
> >
> > Subversion should enforce that a log message is a series of lines of
> > UTF8 text. A "line" is a series of zero or more non-newline
> > characters (qualified by whatever other restrictions we currently put
> > on log messages), followed by a single newline. Thus, every log
> > message would end with a single newline.
>
> I think TSVN already does something like this?
>
> I think it strips all preceding and terminating newlines in log messages.
>
> (Seemed odd to me at first since I would personally have liked to
> preserve a terminating newline. Anyway, got used to it pretty quick,
> nice to see consistency enforced. And it probably saves a byte of
> storage per log message :-).)
>
> If I'm right, and TSVN strips the last newline also, perhaps it's
> worth doing the same (= NOT enforcing a trailing newline, but
> enforcing removing it) in the client libraries, just to keep log
> messages in "TSVN repositories" consistent when/if this new feature is
> introduced..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Jim Blandy <ji...@red-bean.com>.
-1 on the hook (vote, not veto).
+1 on enforcing full lines in the client.
I disbelieve that people would have been upset had '-m' always
appended a newline from the moment it was implemented. They would
have said, "Oh well, I guess that makes sense" and moved on. Pushing
for a hook is classic user interface decision-avoidance syndrome, like
having the "preferences" dialog in a GUI app offer a dozen options
controlling, say, how menus pop up. It's better just to choose a
reasonable behavior that gets the distractions out of the way, and
remove the knobs.
Subversion must impose conventions on log messages, because those log
messages have multiple consumers: web repository browsers, things like
Trac's 'timeline' page, the command-line client, svn2cl, etc. Users
aren't, in fact, free to choose whatever convention suits them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-03-05 15:08:52 -0600, Jonathan Gilbert wrote:
> While CMD.EXE certainly can't handle newlines in command lines, tcsh
> can handle it in this way:
>
> svn ci -m "line one\
> line two\
> line three with trailing newline\
> "
But it's better that users should never learn that, because AFAIK,
with any other language that supports the ending-backslash feature,
a new line is *not* added; it just means that the current line
continues on the next line.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Jonathan Gilbert <o2...@sneakemail.com>.
At 02:33 PM 05/03/2006 -0600, Peter Samuelson wrote:
[snip]
>> The question of whether svn introduced this inconsistency is a topic
>> of some dispute, as you may have noticed :-). One could also do
>>
>> $ svn ci -m "this is a log message ending in a newline
>> "
>
>It has already been noted that tcsh can't do this - I'll add that AFAIK
>cmd.exe can't either. I don't care very much about either of those,
>but there you are.
While CMD.EXE certainly can't handle newlines in command lines, tcsh can
handle it in this way:
svn ci -m "line one\
line two\
line three with trailing newline\
"
Note the trailing backslash on each line but the last.
Jonathan Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Peter Samuelson <pe...@p12n.org>.
[Karl Fogel]
> The user could easily remove that newline -- I've done it before.
> What the user should not do is remove that newline while neglecting to
> also remove
>
> --This line, and those below, will be ignored--
>
> and everything below it (unless the user wants a very bad-looking log
> message, of course).
As an amusing side note, I often remove those lines out of sheer
paranoia. A few weeks ago, I started a commit, but while typing the
log message, realised that I had to make another change before
committing, so I saved the message and aborted. I later committed with
-F, from a different shell that happened to have a different locale.
svn didn't recognise the separator line because it was in the wrong
language, so it used the whole file.
(I blame only myself - but it *was* amusing.)
> > The user mustn't be forced to use a hook to avoid an inconsistency
> > that svn introduced.
>
> The question of whether svn introduced this inconsistency is a topic
> of some dispute, as you may have noticed :-). One could also do
>
> $ svn ci -m "this is a log message ending in a newline
> "
It has already been noted that tcsh can't do this - I'll add that AFAIK
cmd.exe can't either. I don't care very much about either of those,
but there you are.
Just as there are broken shells that don't (easily) allow newlines in
arguments, so there are broken editors that don't allow saving a file
without a newline at the end. pico, for example. I could've sworn
some version of vi wouldn't let me do that either, but I could be
imagining that, since vi is for more sophisticated people.
I would have thrown my support behind the proposal to enforce newlines
in the server, but it seems that's settled now in favor of
log-police.py. Thanks for that script, which I'll install locally and
will probably ship alongside other example hook scripts in Debian's
1.3.x.
Peter
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-03-01 19:53:48 -0600, kfogel@collab.net wrote:
> The user could easily remove that newline -- I've done it before.
> What the user should not do is remove that newline while neglecting to
> also remove
>
> --This line, and those below, will be ignored--
>
> and everything below it (unless the user wants a very bad-looking log
> message, of course).
This is what I do, but this is annoying. I meant that the user
can't remove the newline in the "normal" way to use the editor.
> > The user mustn't be forced to use a hook to avoid an inconsistency
> > that svn introduced.
>
> The question of whether svn introduced this inconsistency is a topic
> of some dispute, as you may have noticed :-). One could also do
>
> $ svn ci -m "this is a log message ending in a newline
> "
>
> That works, it's just highly unusual for anyone to actually do it.
First, it's very uncommon and not intuitive. Secondly, it does not
work under tcsh (this is one of the many known bugs of this crap),
which is a shell still used by many people.
Subversion should be consistent concerning the two *common* ways to
write log messages, even though there are workarounds. If this is
done by a hook, then it should be installed by default.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by kf...@collab.net.
Vincent Lefevre <vi...@vinc17.org> writes:
> I disagree with you. Otherwise svn should be modified so that
> "svn ci -m '...'" and "svn ci" with the log message entered in an
> editor should behave in a consistent manner, taking into account
> that the string after the -m doesn't normally contain a newline,
> and in an editor, the user can't remove the newline before the
> line "--This line, and those below, will be ignored--".
The user could easily remove that newline -- I've done it before.
What the user should not do is remove that newline while neglecting to
also remove
--This line, and those below, will be ignored--
and everything below it (unless the user wants a very bad-looking log
message, of course).
> The user mustn't be forced to use a hook to avoid an inconsistency
> that svn introduced.
The question of whether svn introduced this inconsistency is a topic
of some dispute, as you may have noticed :-). One could also do
$ svn ci -m "this is a log message ending in a newline
"
That works, it's just highly unusual for anyone to actually do it.
Summary: in all three methods of passing a log message, there is a way
for the user to control whether or not that message ends with a
newline. The fact that most users don't take advantage of these
methods is perhaps due to certain interface choices on SVN's part, but
the control is certainly there for those who know how to use it.
Therefore to say that SVN did or didn't introduce the inconsistency is
oversimplifying. The inconsistency is a cooperative venture between
SVN and the user -- either of the two parties could take steps to make
the inconsistency go away, and right now we're discussing whether SVN
should be the one to do it. (In the end I think not, since the hook
solution is available, but I certainly see the arguments for the other
side, having just made them myself :-) ).
I think I may drop out of this thread now, unless something genuinely
new is said. (Not a statement about your post, by the way, more about
the entire thread, which I think has covered all the ground there is
to cover here.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-03-01 14:46:08 -0800, Justin Erenkrantz wrote:
> -1 (vote, not veto). Two principal reasons:
>
> - We should never silently munge the user's UTF-8 commit message
> (such as adding or removing newlines). We should do our best to
> respect the log as provided to us.
I disagree with you. Otherwise svn should be modified so that
"svn ci -m '...'" and "svn ci" with the log message entered in an
editor should behave in a consistent manner, taking into account
that the string after the -m doesn't normally contain a newline,
and in an editor, the user can't remove the newline before the
line "--This line, and those below, will be ignored--".
The user mustn't be forced to use a hook to avoid an inconsistency
that svn introduced.
But IMHO, a normalization of the log file makes sense. After all,
there's already charset conversion to UTF-8 (and EOL conversion?).
> - We should never silently retroactively 'reformat' historical log
> messages.
Why not, but unless the chosen format would produce garbage (e.g. a
format without an additional newline). In such a case (no reformat),
then a tool (based on "svnadmin setlog"?) should be supplied so that
the user can easily reformat all the old logs if he wishes.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Molle Bestefich <mo...@gmail.com>.
kfogel@collab.net wrote:
> THE PROPOSAL:
> -------------
>
> Subversion should enforce that a log message is a series of lines of
> UTF8 text. A "line" is a series of zero or more non-newline
> characters (qualified by whatever other restrictions we currently put
> on log messages), followed by a single newline. Thus, every log
> message would end with a single newline.
I think TSVN already does something like this?
I think it strips all preceding and terminating newlines in log messages.
(Seemed odd to me at first since I would personally have liked to
preserve a terminating newline. Anyway, got used to it pretty quick,
nice to see consistency enforced. And it probably saves a byte of
storage per log message :-).)
If I'm right, and TSVN strips the last newline also, perhaps it's
worth doing the same (= NOT enforcing a trailing newline, but
enforcing removing it) in the client libraries, just to keep log
messages in "TSVN repositories" consistent when/if this new feature is
introduced..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by kf...@collab.net.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> - We should never silently munge the user's UTF-8 commit message (such as
> adding or removing newlines). We should do our best to respect the log as
> provided to us.
> - We should never silently retroactively 'reformat' historical log messages.
>
> If this potential inconsistency bothers any one, they are free to install a
> hook and change the svn:log revprops themselves. However, I don't see the
> pressing need for us to enforce this behavior globally and to do so silently
> without the ability to opt-out. A social solution enforced by hooks is far
> better than having SVN play nanny and to try to enforce arbitrary rules when
> there's no compelling reason to do so. -- justin
Okay. In the end I think that's the best solution too.
Olleg (or someone) want to write a Python hook script to enforce the
convention instead?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Peter Lundblad <pe...@famlundblad.se>.
Justin Erenkrantz writes:
> > THE PROPOSAL:
> > -------------
> >
[...]
> -1 (vote, not veto). Two principal reasons:
+1.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 01 Mar 2006 14:09:28 -0600, kfogel@collab.net <kf...@collab.net> wrote:
>
> THE HOOK ALTERNATIVE:
> ---------------------
+1. (We don't have to do a single thing to allow for this to be
implemented.)
> THE PROPOSAL:
> -------------
>
> Subversion should enforce that a log message is a series of lines of
> UTF8 text. A "line" is a series of zero or more non-newline
> characters (qualified by whatever other restrictions we currently put
> on log messages), followed by a single newline. Thus, every log
> message would end with a single newline.
-1 (vote, not veto). Two principal reasons:
- We should never silently munge the user's UTF-8 commit message (such as
adding or removing newlines). We should do our best to respect the log as
provided to us.
- We should never silently retroactively 'reformat' historical log messages.
If this potential inconsistency bothers any one, they are free to install a
hook and change the svn:log revprops themselves. However, I don't see the
pressing need for us to enforce this behavior globally and to do so silently
without the ability to opt-out. A social solution enforced by hooks is far
better than having SVN play nanny and to try to enforce arbitrary rules when
there's no compelling reason to do so. -- justin
Re: [PROPOSAL] enforce log messages as series of lines
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> THE SPACING CAVEAT:
> -------------------
>
> Some also find the current waste of vertical space annoying: since
> most log messages already end with a newline, adding an unconditional
> extra newline (as we do today) causes a blank line before the
> separator in most cases. However, other people find the logs much
> easier to read with that blank line. Thus it might be that, after
> making all the changes described below, the command-line client should
> *still* print an extra blank line.
>
> THE HOOK ALTERNATIVE:
> ---------------------
IMHO much better after fixing bug write hook to add one newline more to
simulate old buggy behavior, if someone like it.
> In the command-line client, we would:
>
> a) When printing out a log message, no longer unconditionally print
> an extra newline in 'svn log' output to ensure that the log
> message body doesn't scrunch up against the following separator
> line. Instead, as a compatibility measure, check to see if the
> message already ends with a single newline; if it does, print
> nothing extra, otherwise, print a single extra newline and
> adjust the header's line count appropriately. (*** But see
> "Spacing" below ***).
My path do only this.
Enforce new format for log messages is cool, but:
1. This is not topic of my patch. (offtopic :) )
2. Do not anyone agree with it.
I agree to strictly define format of log messages (and other text
properties) someday, but I insist on my patch only. Because it is part
of the great Karl Fogel plan and :
Current format of text properties is not strict. Newline may or may not
be at the end. Clients is not enforced always place newline at the end
and is not enforced to remove it if user didn't type it manualy. Server
do not enforce trailing newline on input or output log messages. This is
current reality and some developers don't want change it.
O'key. Let see behavior of "svn log" in current reality. It's commonly
buggy. Most user don't type "enter" at the end of log message, but they
see blank line at the end in svn log later, because "svn log" always
expect log message without trailing newline. With current none strict
format of log messages this behavior is buggy.
What will be after the patch. "svn log" will show the same log message,
as user type it in most cases. I see only one exclusion, when behavior
will be wrong after the patch. Imagine someone want to place blank line
at the end. And do it like:
svn ci -m "want blank line at the end
"
Blank line will disappeare in log output, it's wrong but case is very
unusual. But if someone place blankline in text editor at the end, svn
log will show it as is.
Lets compare subversion before and after my patch. Before and after my
patch subversion do wrong sometimes. But before my patch subversion do
wrong as usual. After my patch in very unusual and artificial cases.
After my patch subversion will be better. It is good reason, isn't it?
And if you will enforce strict format of text properties in very far
future (in version 2.x), my patch will be compatible.
--
Olleg Samoylov
Re: [PROPOSAL] enforce log messages as series of lines
Posted by kf...@collab.net.
kfogel@collab.net writes:
> This proposal results from the recent thread around Olleg Samoylov's
> patch to the command line client:
>
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=433505
>
> (This proposal is not quite the same as Olleg's patch, however.)
I forgot to credit Greg Hudson, who I think first proposed something
similar to this a long time ago. (If he didn't, and doesn't want to
be blamed for this proposal, then sorry Greg :-) ).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
>>>THE HOOK ALTERNATIVE:
>>+1
>>
>>>THE PROPOSAL:
>>-1
As I undestand, this mean next. If someone want reformat log messages on
server side, he must use hook for it.
But what about client software? On input only client software know
exactly does or does not user want put blank line at the end of log
message. EOL (end of line) before EOF (end of file) is de facto standard
for text files and all text editor do it (except for hex editors). This
is not mean blank line at the end and "svn ci -F" and "svn ci" must know
that. On output only client software know exactly is newline at the end
needed. For instance "svn log" must always put it, while some GUI client
should not.
Hook don't solve all problems. But if you do it, can you also make hook
to remove all trailing whitespaces, please. :) Because this is
compatible with current behavior of "svn log".
--
Olleg Samoylov
Re: [PATCH] hook script for log message newline enforcement
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> When used with --all-revs does it take long to rewrite, say, 100,000
> revision properties? How about checking if log_message[-1] is already
> '\n' and skipping the change?
Or rather, checking if orig log_message and new log_message are equal,
and doing nothing if they are...
r18709, thanks.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> def fix_up_rev(fs, revnum):
> "Fix up the log message for revision REVNUM in FS."
> log_message = svn.fs.svn_fs_revision_prop(fs, revnum, 'svn:log')
> if log_message is not None:
> log_message = log_message.rstrip() + "\n"
> svn.fs.svn_fs_change_rev_prop(fs, revnum, "svn:log", log_message)
When used with --all-revs does it take long to rewrite, say, 100,000
revision properties? How about checking if log_message[-1] is already
'\n' and skipping the change?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> kfogel@collab.net writes:
>
> > if len(args) > 1:
> > sys.stderr.write("ERROR: only one argument allowed (the repository).\n\n")
> > usage(sys.stderr)
> > sys.exit(1)
> >
> > repos_path = args[0]
>
> and if len(args) == 0?
Thank you, will fix.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] hook script for log message newline enforcement
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> if len(args) > 1:
> sys.stderr.write("ERROR: only one argument allowed (the repository).\n\n")
> usage(sys.stderr)
> sys.exit(1)
>
> repos_path = args[0]
and if len(args) == 0?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] hook script for log message newline enforcement
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> > THE HOOK ALTERNATIVE:
> +1
> > THE PROPOSAL:
> -1
Well, I didn't want to be all talk and no action :-).
Please review this pre-commit hook script. Once any needed tweaks are
made, I'll check it into tools/hook-scripts/. I'm in favor of running
this on Subversion's own repository, but that's a separate thread;
I'll bring it up after the script is committed.
--------------------8-<-------cut-here---------8-<-----------------------
#!/usr/bin/python
# log-police.py: Ensure that log messages end with a single newline.
# See usage() function for details, or just run with no arguments.
import os
import sys
import getopt
import svn
import svn.fs
import svn.repos
import svn.core
# Pretend we have true booleans on older python versions
try:
True
except:
True = 1
False = 0
def fix_up_txn(fs, txn_name):
"Fix up the log message for txn TXN_NAME in FS."
txn = svn.fs.svn_fs_open_txn(fs, txn_name)
log_message = svn.fs.svn_fs_txn_prop(txn, "svn:log")
if log_message is not None:
log_message = log_message.rstrip() + "\n"
svn.fs.svn_fs_change_txn_prop(txn, "svn:log", log_message)
def fix_up_rev(fs, revnum):
"Fix up the log message for revision REVNUM in FS."
log_message = svn.fs.svn_fs_revision_prop(fs, revnum, 'svn:log')
if log_message is not None:
log_message = log_message.rstrip() + "\n"
svn.fs.svn_fs_change_rev_prop(fs, revnum, "svn:log", log_message)
def main(ignored_pool, argv):
repos_path = None
txn_name = None
rev_name = None
all_revs = False
try:
opts, args = getopt.getopt(argv[1:], 't:r:h?', ["help", "all-revs"])
except:
sys.stderr.write("ERROR: problem processing arguments / options.\n\n")
usage(sys.stderr)
sys.exit(1)
for opt, value in opts:
if opt == '--help' or opt == '-h' or opt == '-?':
usage()
sys.exit(0)
elif opt == '-t':
txn_name = value
elif opt == '-r':
rev_name = value
elif opt == '--all-revs':
all_revs = True
else:
sys.stderr.write("ERROR: unknown option '%s'.\n\n" % opt)
usage(sys.stderr)
sys.exit(1)
if txn_name is not None and rev_name is not None:
sys.stderr.write("ERROR: Cannot pass both -t and -r.\n\n")
usage(sys.stderr)
sys.exit(1)
if txn_name is not None and all_revs:
sys.stderr.write("ERROR: Cannot pass --all-revs with -t.\n\n")
usage(sys.stderr)
sys.exit(1)
if rev_name is not None and all_revs:
sys.stderr.write("ERROR: Cannot pass --all-revs with -r.\n\n")
usage(sys.stderr)
sys.exit(1)
if rev_name is None and txn_name is None and not all_revs:
usage(sys.stderr)
sys.exit(1)
if len(args) > 1:
sys.stderr.write("ERROR: only one argument allowed (the repository).\n\n")
usage(sys.stderr)
sys.exit(1)
repos_path = args[0]
# A non-bindings version of this could be implemented by calling out
# to 'svnlook getlog' and 'svnadmin setlog'. However, using the
# bindings results in much simpler code.
fs = svn.repos.svn_repos_fs(svn.repos.svn_repos_open(repos_path))
if txn_name is not None:
fix_up_txn(fs, txn_name)
elif rev_name is not None:
fix_up_rev(fs, int(rev_name))
elif all_revs:
last_youngest = 0
while True:
youngest = svn.fs.svn_fs_youngest_rev(fs)
if youngest >= last_youngest:
for this_rev in range(last_youngest, youngest + 1):
fix_up_rev(fs, this_rev)
last_youngest = youngest + 1
else:
break
def usage(outfile=sys.stdout):
outfile.write("USAGE: %s [-t TXN_NAME | -r REV_NUM | --all-revs] REPOS\n"
% (sys.argv[0]))
outfile.write(
"\n"
"Ensure that log messages end with exactly one newline and no\n"
"other whitespace characters. Use as a pre-commit hook by passing\n"
"'-t TXN_NAME'; fix up a single revision by passing '-r REV_NUM';\n"
"fix up all revisions by passing '--all-revs'. (When used as a\n"
"pre-commit hook, may modify the svn:log property on the txn.)\n")
if __name__ == '__main__':
sys.exit(svn.core.run_app(main, sys.argv))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL] enforce log messages as series of lines
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net wrote:
> THE HOOK ALTERNATIVE:
+1
> THE PROPOSAL:
-1
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
[PROPOSAL] enforce log messages as series of lines
Posted by kf...@collab.net.
This proposal results from the recent thread around Olleg Samoylov's
patch to the command line client:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=433505
(This proposal is not quite the same as Olleg's patch, however.)
Whatever we decide here, I'd like to record it in issue #1870, so we
can remember and not go around this circle every six months :-).
THE PROBLEM:
------------
Currently 'svn log' output is needlessly inconsistent about whether or
not there is a blank line before the separator. For example, see
r18480 and r18479 in Subversion's repository, compare them with other
nearby revisions.
Also, some users get confused by the fact that log messages committed
with -m versus -F versus $EDITOR can have different results (in fact,
users could achieve identicalness, but the means of doing so are
fairly unintuitive for most people).
THE SPACING CAVEAT:
-------------------
Some also find the current waste of vertical space annoying: since
most log messages already end with a newline, adding an unconditional
extra newline (as we do today) causes a blank line before the
separator in most cases. However, other people find the logs much
easier to read with that blank line. Thus it might be that, after
making all the changes described below, the command-line client should
*still* print an extra blank line.
THE HOOK ALTERNATIVE:
---------------------
(We're just about to get to the proposal, really, just one more
thing...)
Most of what people want can be achieved with hooks. Just have a hook
that enforces whatever log message conventions you want, and then fix
up your old messages to conform to the new format. The hook program
can even be written to run in a standalone mode to make it easy for
the admin to fix up all the old revisions. Of course, you still have
to install the hook, and maybe it's better for Subversion to do what
most people expect by default. However, keep the hook alternative in
mind.
THE PROPOSAL:
-------------
Subversion should enforce that a log message is a series of lines of
UTF8 text. A "line" is a series of zero or more non-newline
characters (qualified by whatever other restrictions we currently put
on log messages), followed by a single newline. Thus, every log
message would end with a single newline.
(Note that subversion already enforces that log messages are stored as
UTF8, although of course they may be printed in a different encoding
in the client locale)
On the server side, we would silently enforce the new format:
1. On arrival, log messages that end with something other than a
newline would have a single newline appended. (For convenience,
log messages that end with multiple newlines could have that
reduced to a single newline, but IMHO that is an optional part
of this proposal. Similar statement applies to log messages
that end with a mixture of other whitespace chars -- e.g.,
SPACE, TAB, CR -- and newlines.)
2. On retrieval, log messages would also be checked & similarly
reformatted. This takes care of revisions that were committed
before the server was upgraded. (We may or may not replace the
old svn:log prop with the new, I don't think it matters much.)
In the command-line client, we would:
a) When printing out a log message, no longer unconditionally print
an extra newline in 'svn log' output to ensure that the log
message body doesn't scrunch up against the following separator
line. Instead, as a compatibility measure, check to see if the
message already ends with a single newline; if it does, print
nothing extra, otherwise, print a single extra newline and
adjust the header's line count appropriately. (*** But see
"Spacing" below ***).
b) When taking a log message as input, enforce the same things the
newer servers would enforce (thus if you commit with a new
client to an old server, someone else running 'svn log' against
that server with an old client will still get the new hotness.)
After this, the only way to run into the old behavior would be to do
'svn log' with an old client, against an old server, retrieving the
log message for a revision that was also committed with an old client.
FWIW, I'm -1 on applying Olleg's patch by itself. I think we should
either enforce a log message convention throughout the entire system,
or stick with the current behavior (which still leaves open the
possibility of a hook solution).
Thoughts?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by John Peacock <jp...@rowman.com>.
Alan Barrett wrote:
> I believe that enforcement of a log message as a sequence of lines
> should be done on the server side.
+1 (now that Olleg has explained it slowly for me ;-)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by kf...@collab.net.
Alan Barrett <ap...@cequrux.com> writes:
> On Tue, 28 Feb 2006, kfogel@collab.net wrote:
> > On the other hand, I do favor enforcing the format of log messages on
> > the repository side instead (an idea first proposed by Greg Hudson, if
> > I remember correctly). In other words, on the repository side we'd do
> > the same thing: ensure there's always exactly one trailng newline on
> > the log message. This also munges the user's data, in the same way.
> > It would fix legacy svn:log properties too as necessary.
>
> Yes, please. I find it surprising that
>
> svn commit -m "message"
>
> does not behave like
>
> echo "message" >messagefile
> svn commit -F messagefile
Well, that just has to do with the behavior of echo, which appends a
newline by default. If you were to do
echo -n "message" > messagefile
svn commit -F messagefile
then you would get the same behavior as 'svn commit -m "message"'.
(Again, I'm not opposed to Subversion enforcing line conventions. I'm
just pointing out that the user-supplied data really did differ in
your two cases.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Alan Barrett <ap...@cequrux.com>.
On Tue, 28 Feb 2006, kfogel@collab.net wrote:
> On the other hand, I do favor enforcing the format of log messages on
> the repository side instead (an idea first proposed by Greg Hudson, if
> I remember correctly). In other words, on the repository side we'd do
> the same thing: ensure there's always exactly one trailng newline on
> the log message. This also munges the user's data, in the same way.
> It would fix legacy svn:log properties too as necessary.
Yes, please. I find it surprising that
svn commit -m "message"
does not behave like
echo "message" >messagefile
svn commit -F messagefile
or
svn commit
[type "message" as the only line above the "this line will be
removed" marker]
I'd call it a bug that "svn commit -m" fails to append a newline to the
message. (CVS handles this correctly, by adding a newline to messages
that do not already end with a newline, and not adding a newline to
messages that already end with a newline.)
> The server-side solution has the advantage of solving the problem for
> all clients. I think I'd be +1 on your patch, as a compatibility
> measure for older repositories, *if* we also implemented this behavior
> on the server side. But doing only the client change seems wrong: log
> messages are repository data, they should be in the correct format
> when they are stored/retrieved in the repository.
>
> Thoughts?
I believe that enforcement of a log message as a sequence of lines
should be done on the server side.
--apb (Alan Barrett)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by kf...@collab.net.
Vincent Lefevre <vi...@vinc17.org> writes:
> But is it important to recover the original log data? I don't think
> it is. The server should do some form of normalization (I prefer this
> term to "munging"), IMHO.
>
> For instance, one could decide that the number of ending newline
> characters must be fixed (choose either 0 or 1). I don't think it
> makes sense to have a variable number of newline characters (when
> this happens, it happens by accident).
>
> Also, is the EOL for log messages always \n on the server, or does it
> depend on the platform of the client that submitted the log message?
> IMHO, it should always be \n (so that it can be correctly converted
> on the client side when displaying the log). But if such a conversion
> occurs, this is "munging" too. :)
Fair enough -- yes, we already "munge" / "normalize" log data anyway,
though I believe it's the client that does it, not the server.
(However, I still think I like the hook solution better. Less work
for us to maintain, all the code in one place for inspection, etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-03-01 12:09:24 -0600, kfogel@collab.net wrote:
> In Subversion today, it is possible (via the 'svn log' command) to
> recover *exactly* the log message the committer entered. This is
> because the addition of the extra newline is unconditional; if you
> just strip that newline, you get the original log message. With your
> patch, it is no longer possible to recover the exact log message,
> because the output of 'svn log' will not reveal whether an extra
> newline was added or not.
>
> I'm not saying this is horrible; indeed, I'm advocating a solution
> that has similar properties to your patch. However, there is no
> denying that it would simply not be possible to recover the original
> log data with your patch, because you can't know exactly where the
> original data ends. (I'm talking about via the command line client
> outpu -- obviously you could use direct APIs to get the log data).
>
> When I say "munge the data", what I mean is "make the exact original
> data unrecoverable". And what I said is true, but fortunately, the
> kind of munging we're talking about does not harm the meaning of the
> log message, so it may be permissible. It's still munging, however.
But is it important to recover the original log data? I don't think
it is. The server should do some form of normalization (I prefer this
term to "munging"), IMHO.
For instance, one could decide that the number of ending newline
characters must be fixed (choose either 0 or 1). I don't think it
makes sense to have a variable number of newline characters (when
this happens, it happens by accident).
Also, is the EOL for log messages always \n on the server, or does it
depend on the platform of the client that submitted the log message?
IMHO, it should always be \n (so that it can be correctly converted
on the client side when displaying the log). But if such a conversion
occurs, this is "munging" too. :)
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> I do not mungle log data. I show it as is. But if log data haven't
> trailing newline some bad things happens, output is jammed and count
> of lines =0. This is bad, so I increment count of lines and add
> newline to the end. This is all what doing my patch.
Here is what I am saying:
In Subversion today, it is possible (via the 'svn log' command) to
recover *exactly* the log message the committer entered. This is
because the addition of the extra newline is unconditional; if you
just strip that newline, you get the original log message. With your
patch, it is no longer possible to recover the exact log message,
because the output of 'svn log' will not reveal whether an extra
newline was added or not.
I'm not saying this is horrible; indeed, I'm advocating a solution
that has similar properties to your patch. However, there is no
denying that it would simply not be possible to recover the original
log data with your patch, because you can't know exactly where the
original data ends. (I'm talking about via the command line client
outpu -- obviously you could use direct APIs to get the log data).
When I say "munge the data", what I mean is "make the exact original
data unrecoverable". And what I said is true, but fortunately, the
kind of munging we're talking about does not harm the meaning of the
log message, so it may be permissible. It's still munging, however.
> > The server-side solution has the advantage of solving the problem for
> > all clients. I think I'd be +1 on your patch, as a compatibility
> > measure for older repositories, *if* we also implemented this behavior
> > on the server side. But doing only the client change seems wrong: log
> > messages are repository data, they should be in the correct format
> > when they are stored/retrieved in the repository.
>
> Well, but client may work with old servers thus client must be patched too.
Uh, right. That's what I said, in the text you quoted.
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> Olleg Samoylov <ol...@mipt.ru> writes:
>>I'll explain. Log message in version 1.x may have (in case of text
>>editor) or may have not (in case of "svn ci -m") trailing newline. And
>>this is not issue of text editor, trailing newline is appeared after
>>removing "--This line, and those below, will be ignored--", this issue
>>is entirely of subversion.
>
> Well, that depends how you define "line". If you define it to mean a
> bunch of non-newline characters followed by a newline (as I was
> proposing for a solution, in fact), then Subversion is doing exactly
> what it promises to do.
Where? In case "svn ci -m " or in case "svn ci"? :) In one case
subversion is not doing exactly what it promises to do, isn't it? :)
>>After patch "svn log" will check for trailing newline in log message
>>and only when it's needed add newline and increment "lines".
>
> So, my original objection to this patch was that it fixes the problem
> by misrepresenting the data (in a trival way, I admit). Right now,
> Subversion *always* adds a newline when displaying the log message, so
> you can always know exactly what the person actually entered for the
> log message. After this patch, that data is no longer recoverable.
Key words is "what the person actually entered for the log message"!
Trailing newline must be shown only when person actually enter it! (When
person press "enter" at the end of log message).
kfogel@collab.net wrote:
> Olleg Samoylov <ol...@mipt.ru> writes:
> I do not consider the preceding newline to be part of the special
> "--Text...will be removed--" line, but rather the end of the line
> before. There are good reasons for this: all users seeing a file like
> "\nsometext" or "\nsometext\n" will consider it to have at least two
> lines. Many people would consider both "sometext" and "sometext\n" to
> be one line long. To me, this all means that a newline is clearly
> part of the line before it, not the line after it.
It's not so easy. :)
When you type one line text string in text editor you don't press
"enter" at the end, isn't it? When you want add one text string more,
you former press "enter" (insert newline) and latter add text, isn't it?
> Not that any of this matters. If we agree that log messages should be
> a series of lines, where each line ends with a newline, then we should
> enforce that. If we do not agree, then we must not munge log data at
> all (i.e., we must ensure that the original log is recoverable, which
> the current behavior does).
I do not mungle log data. I show it as is. But if log data haven't
trailing newline some bad things happens, output is jammed and count of
lines =0. This is bad, so I increment count of lines and add newline to
the end. This is all what doing my patch.
> The server-side solution has the advantage of solving the problem for
> all clients. I think I'd be +1 on your patch, as a compatibility
> measure for older repositories, *if* we also implemented this behavior
> on the server side. But doing only the client change seems wrong: log
> messages are repository data, they should be in the correct format
> when they are stored/retrieved in the repository.
Well, but client may work with old servers thus client must be patched too.
I am not developer of subversion, only user. No matter for me how you
keep my log messages. I what to see exactly what I type.
Force trailing newline is good, besause compatible with most text
editors, not only you like it. :) But I don't know subversion enough to
fix it on server side.
--
Olleg Samoylov
Re: patch newline in log messages
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> Only for a subversion developer. :)
> When a common user write a log message in a text editor, for instance
> one line, user expect a one line log message, isn't it? After "svn
> log", user is very surprised when see two line log message, especially
> text string "|lines=2". This behaviour is unexpected and unpredictable
> for everyone, except subversion developers. Do you agree?
>
> This bug is not severe, but looked like an ink blot on a white shirt.
I agree the behavior is unexpected and mildly surprising. Ink blot on
a white shirt is a good analogy.
> > I'm not yet convinced there is a bug here worth fixing. Since this
> > thread's subject and body no longer contain the issue number, and
>
> According to rules issue must be placed after a dispute in a mail thread.
Sorry, I saw the word "issue" and assumed there was one filed already,
I understand what you meant now.
> > there is no description of your patch's behavior in your mail here,
> > it's difficult for me to track down exactly what your patch does.
>
> I'll explain. Log message in version 1.x may have (in case of text
> editor) or may have not (in case of "svn ci -m") trailing newline. And
> this is not issue of text editor, trailing newline is appeared after
> removing "--This line, and those below, will be ignored--", this issue
> is entirely of subversion.
Well, that depends how you define "line". If you define it to mean a
bunch of non-newline characters followed by a newline (as I was
proposing for a solution, in fact), then Subversion is doing exactly
what it promises to do.
> Old "svn log" behavior is always add one newline more to insure text
> will not be jammed.
Right.
> After patch "svn log" will check for trailing newline in log message
> and only when it's needed add newline and increment "lines".
So, my original objection to this patch was that it fixes the problem
by misrepresenting the data (in a trival way, I admit). Right now,
Subversion *always* adds a newline when displaying the log message, so
you can always know exactly what the person actually entered for the
log message. After this patch, that data is no longer recoverable.
On the other hand, I do favor enforcing the format of log messages on
the repository side instead (an idea first proposed by Greg Hudson, if
I remember correctly). In other words, on the repository side we'd do
the same thing: ensure there's always exactly one trailng newline on
the log message. This also munges the user's data, in the same way.
It would fix legacy svn:log properties too as necessary.
The server-side solution has the advantage of solving the problem for
all clients. I think I'd be +1 on your patch, as a compatibility
measure for older repositories, *if* we also implemented this behavior
on the server side. But doing only the client change seems wrong: log
messages are repository data, they should be in the correct format
when they are stored/retrieved in the repository.
Thoughts?
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> Philip Martin wrote:
> > The two log messages "foo" and "foo\n" currently show up as different
> > because they are different. Why is that bad? Why should Subversion
> > hide the difference? If hiding the difference really is the right
> > thing to do then what about: "foo\n\n", "\n\nfoo\n\n", "foo \n",
> > should they be made to look the same as well?
>
> Because user don't enter newline. User enter the same message with
> "svn ci -m" and with "svn ci" and text editor. Subversion in case of
> text editor add '\n' at the end of log message, in case of "svn ci -m"
> not.
With the text editor, the user left the newline, though probably
unintentionally. The user *could* have removed that newline, but most
users do not.
I do not consider the preceding newline to be part of the special
"--Text...will be removed--" line, but rather the end of the line
before. There are good reasons for this: all users seeing a file like
"\nsometext" or "\nsometext\n" will consider it to have at least two
lines. Many people would consider both "sometext" and "sometext\n" to
be one line long. To me, this all means that a newline is clearly
part of the line before it, not the line after it.
Not that any of this matters. If we agree that log messages should be
a series of lines, where each line ends with a newline, then we should
enforce that. If we do not agree, then we must not munge log data at
all (i.e., we must ensure that the original log is recoverable, which
the current behavior does).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
John Peacock wrote:
> Whether the *editor* appends a newline or not is up to the editor
> (indeed, some can be configured to not do so), but it essentially
> unknowable to Subversion. As such, it is impossible to come up with a
> single heuristic that covers all situations.
You are not right. I explain again and again. Look at common log message
in editor:
my log message\n
--This line, and those below, will be ignored--\n
\n
M a\n
EOF
Newline is added before EOF by mostly common editors. But this newline
is removed by subversion. Subversion keep newline before "--This line,
and those below, will be ignored--".
Please, read mail thread from the beginning before post new messages.
--
Olleg Samoylov
Re: patch newline in log messages
Posted by John Peacock <jp...@rowman.com>.
Olleg Samoylov wrote:
> Because user don't enter newline. User enter the same message with "svn
> ci -m" and with "svn ci" and text editor. Subversion in case of text
> editor add '\n' at the end of log message, in case of "svn ci -m" not.
>
> "svn log" must show only log message writed by user, nor more nor less.
Whether the *editor* appends a newline or not is up to the editor
(indeed, some can be configured to not do so), but it essentially
unknowable to Subversion. As such, it is impossible to come up with a
single heuristic that covers all situations.
If the trailing newline offends you, write your log entries into a file
using the equivalent of `cat > logfile` and then commit using -F. It
may also be possible to write a pre-commit hook to clean the log file.
No matter how violently you disagree with the current Subversion
behavior, all you are accomplishing now is pissing people off. Please
let it go.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
Philip Martin wrote:
> The two log messages "foo" and "foo\n" currently show up as different
> because they are different. Why is that bad? Why should Subversion
> hide the difference? If hiding the difference really is the right
> thing to do then what about: "foo\n\n", "\n\nfoo\n\n", "foo \n",
> should they be made to look the same as well?
Because user don't enter newline. User enter the same message with "svn
ci -m" and with "svn ci" and text editor. Subversion in case of text
editor add '\n' at the end of log message, in case of "svn ci -m" not.
"svn log" must show only log message writed by user, nor more nor less.
If you can't undestand yet, try read this mail thread from the beginning.
--
Olleg Samoylov
Re: patch newline in log messages
Posted by Philip Martin <ph...@codematters.co.uk>.
Olleg Samoylov <ol...@mipt.ru> writes:
> kfogel@collab.net wrote:
>> Why is this a severe issue? The behavior is perfectly predictable.
>
> Only for a subversion developer. :)
> When a common user write a log message in a text editor, for instance
> one line, user expect a one line log message, isn't it? After "svn
> log", user is very surprised when see two line log message, especially
> text string "|lines=2". This behaviour is unexpected and unpredictable
> for everyone, except subversion developers. Do you agree?
The two log messages "foo" and "foo\n" currently show up as different
because they are different. Why is that bad? Why should Subversion
hide the difference? If hiding the difference really is the right
thing to do then what about: "foo\n\n", "\n\nfoo\n\n", "foo \n",
should they be made to look the same as well?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
kfogel@collab.net wrote:
> Why is this a severe issue? The behavior is perfectly predictable.
Only for a subversion developer. :)
When a common user write a log message in a text editor, for instance
one line, user expect a one line log message, isn't it? After "svn log",
user is very surprised when see two line log message, especially text
string "|lines=2". This behaviour is unexpected and unpredictable for
everyone, except subversion developers. Do you agree?
This bug is not severe, but looked like an ink blot on a white shirt.
> I'm not yet convinced there is a bug here worth fixing. Since this
> thread's subject and body no longer contain the issue number, and
According to rules issue must be placed after a dispute in a mail thread.
> there is no description of your patch's behavior in your mail here,
> it's difficult for me to track down exactly what your patch does.
I'll explain. Log message in version 1.x may have (in case of text
editor) or may have not (in case of "svn ci -m") trailing newline. And
this is not issue of text editor, trailing newline is appeared after
removing "--This line, and those below, will be ignored--", this issue
is entirely of subversion.
Old "svn log" behavior is always add one newline more to insure text
will not be jammed.
After patch "svn log" will check for trailing newline in log message and
only when it's needed add newline and increment "lines".
--
Olleg Samoylov
Re: patch newline in log messages
Posted by kf...@collab.net.
Olleg Samoylov <ol...@mipt.ru> writes:
> I insist on my patch, because:
> 1. There is issue in "svn log". "svn log" don't check trailing newline
> and always add one newline more to the end of a log message.
Why is this a severe issue? The behavior is perfectly predictable.
> And you can help. IMHO buddies from "issue tracker" read only last
> message in mail thread and think that is "conclusion of discussion".
> Please, simple answer, for instance: "I agree, the bug is exist and
> your patch partially fix it." :)
:-)
I'm not yet convinced there is a bug here worth fixing. Since this
thread's subject and body no longer contain the issue number, and
there is no description of your patch's behavior in your mail here,
it's difficult for me to track down exactly what your patch does.
Maybe I'd think differently if I knew.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
As I undestand there are two radical solutions. Always put newline at
the end of log messages or always remove newline (and may be other white
space) from log messages (and may be from other properties). All of them
change svn repositories and can not be implemented before version 2.x.
I insist on my patch, because:
1. There is issue in "svn log". "svn log" don't check trailing newline
and always add one newline more to the end of a log message.
2. My patch is only fix this issue in "svn log". It don't require change
svn repositiories and may be applied in version 1.x.
3. If in the far future discussion will be finished to always add or
remove trailing newline, patch will be work well and will not break code.
And you can help. IMHO buddies from "issue tracker" read only last
message in mail thread and think that is "conclusion of discussion".
Please, simple answer, for instance: "I agree, the bug is exist and your
patch partially fix it." :)
--
Olleg Samoylov
Re: patch newline in log messages
Posted by Julian Foad <ju...@btopenworld.com>.
Olleg Samoylov wrote:
> Julian Foad wrote:
>> Issue #1870 "Don't add extra blank line to log messages" is the right
>> one. It contains a patch to not add an extra line to an EMPTY log
>> message, but it should discuss the whole issue of trailing newlines.
>
> I already sent patch half year ago to remove trailing newlines at stage
> "svn commit". There was a great discussion about it. And you took part
> in it also. But in spite of your support, Karl Fogel rejected it. Reason
> was:
>
>> I am totally, completely opposed to Subversion taking the trailing
>> newline off my log messages. Take my house, take my car, take my
>> piano (well, no, leave the piano please) but DO NOT TAKE my trailing
>> newline.
>
> And from Greg Hudson:
>
>> in the ideal case, svn:log properties should be thought of as a series
>> of lines, and we should ensure that they are by requiring that they have
>> a final newline.
>>
>> Since we can't (or at least don't want to) modify the svn:log properties
>> of existing repositories, we would also append a final newline in the
>> display code to svn:log properties which don't have one.
OK, so Karl doesn't want his trailing newlines removed. Greg's quote is a
conditional suggestion ("we would ...") out of context so it doesn't mean much
by itself. These are only the opinions of certain people at a certain time,
and don't necessarily mean that we will or won't do anything in particular.
> Now I write patch worked at stage "svn log". What I need to do also to
> fix this very old issue?
Well, it's no good any of us just sending patches, because we haven't agreed on
what behaviour we want. We need to discuss the behavioural requirements, and
find solutions that are acceptable to everybody.
For example, if the problem is that you want consistent spacing at the end of
each log message in your own repositories, here is one solution that may be
acceptable to you and doesn't require changing Subversion at all: fix up all
the old log messages, and write a pre-commit hook script that trims off or
normalises any trailing newline(s) in the log message about to be committed.
If the problem is that you want to see log messages in a consistent style in
other people's repositories, then a different solution is required.
For those people who say the log message must be retrieved exactly as it was
provided, we can try arguing that as long as it is retrievable (e.g. with "svn
log --xml" or "svn propget svn:log") the default display of "svn log" need not
be in this exact form.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
Julian Foad wrote:
Hi Julian :).
> Olleg Samoylov wrote:
> Issue #1870 "Don't add extra blank line to log messages" is the right
> one. It contains a patch to not add an extra line to an EMPTY log
> message, but it should discuss the whole issue of trailing newlines.
I already sent patch half year ago to remove trailing newlines at stage
"svn commit". There was a great discussion about it. And you took part
in it also. But in spite of your support, Karl Fogel rejected it. Reason
was:
> I am totally, completely opposed to Subversion taking the trailing
> newline off my log messages. Take my house, take my car, take my
> piano (well, no, leave the piano please) but DO NOT TAKE my trailing
> newline.
And from Greg Hudson:
> in the ideal case, svn:log properties should be thought of as a series
> of lines, and we should ensure that they are by requiring that they have
> a final newline.
>
> Since we can't (or at least don't want to) modify the svn:log properties
> of existing repositories, we would also append a final newline in the
> display code to svn:log properties which don't have one.
Now I write patch worked at stage "svn log". What I need to do also to
fix this very old issue?
--
Olleg Samoylov
Re: patch newline in log messages
Posted by Julian Foad <ju...@btopenworld.com>.
Olleg Samoylov wrote:
> Is discusion closed and I am free to send patch to "Issue tracker"?
I think it would be good to have an issue about this, even if it is soon closed
as "Won't fix", because people ask about it repeatedly.
Issue #1870 "Don't add extra blank line to log messages" is the right one. It
contains a patch to not add an extra line to an EMPTY log message, but it
should discuss the whole issue of trailing newlines.
Please add a comment to that issue saying what behaviour you would like, and why.
We will not change the behaviour before Subversion v2.0. There is little point
in attaching your patch, because there are many ways to address the problem
(e.g. we might want to remove all of the newlines at the end of a message), and
we are unlikely to use exactly that solution, and the code will have changed by
the time we do so, and it is easy to implement any solution. (For these
reasons, there's no point in having my patch stored in that issue either, but
that's how the issue came to be filed.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
Is discusion closed and I am free to send patch to "Issue tracker"?
--
Olleg Samoylov
Re: patch newline in log messages
Posted by Olleg Samoylov <ol...@mipt.ru>.
Garrett Rooney wrote:
> On 2/17/06, Olleg Samoylov <ol...@mipt.ru> wrote:
>
>> Sometimes newline exits at the end of log messages. Sometimes not. This
>> is patch "svn log" to check of trailing newline and put newline at the
>> end only if it's needed.
>
>
>
> This is because the newline comes from the editor, a lack of a newline
> usually indicates that someone used -m to pass a message. I'm -1 to
> ripping the newlines off, the user put them there (via their text
> editor) and we have no business removing them.
There was several patches to remove newline at the end after text
editor, for instance http://svn.haxx.se/dev/archive-2005-07/0766.shtml.
But Karl Fogel reject all of it. Reason - log messages must have newline
at the end, this is preffered (he like it).
This patch is to hide newline at the end on log output.
I attach new version of patch, some better.
--
Olleg Samoylov
Re: patch newline in log messages
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/17/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> This is because the newline comes from the editor, a lack of a newline
> usually indicates that someone used -m to pass a message. I'm -1 to
> ripping the newlines off, the user put them there (via their text
> editor) and we have no business removing them.
Ditto. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: patch newline in log messages
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/17/06, Olleg Samoylov <ol...@mipt.ru> wrote:
> Sometimes newline exits at the end of log messages. Sometimes not. This
> is patch "svn log" to check of trailing newline and put newline at the
> end only if it's needed.
This is because the newline comes from the editor, a lack of a newline
usually indicates that someone used -m to pass a message. I'm -1 to
ripping the newlines off, the user put them there (via their text
editor) and we have no business removing them.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org