You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2006/01/28 21:11:37 UTC
[VOTE] space before paren policy
Hi, everyone,
After some discussion on IRC, I decided to call for a vote regarding this
space-before-parens discussion. We clearly don't reach a concensus and
there doesn't seem to be any more arguments put forward. The interested
can read this thread here:
http://svn.haxx.se/dev/archive-2006-01/0820.shtml
(This is the relevant subthread where the proposal was raised.)
There are three alternatives to vote on; you can vote +1, -1, +0 or -0 for
each. Note that -1 is not a veto, but just a vote against that
alternative. The votes for each alternative will be summed up and the
alternative with the highest sum wins. Everyone may vote, but only full
committer votes are binding.
If there are objections to these voting rules, we'll have to cancel this
process and resolve our voting process formally first.
Voting closes Thursday 2006-02-02T00:00:00Z. I will post a summary after
that date.
The alternatives are:
space-before-paren:
Require that there is a space between a function (or macro, but not for
the macro definition, of course) name and the following parentheses for
code that is added and that is not part of files or modules where another
style is already in use.
no-space-before-paren:
Require that there is no space between a function (or macro, but not for
the macro definition, of course) name and the following parentheses for
code that is added and that is not already part of files or modules where
another style is already in use.
big-compromise:
No change to hacking.html (see "Coding style" for the current text). This
allows the author of new code to choose the style.
Note that this applies to core C code.
-1 -0 +0 +1 Alternative
[ ] [ ] [ ] [ ] space-before-paren
[ ] [ ] [ ] [ ] no-space-before-paren
[ ] [ ] [ ] [ ] big-compromise
Please reply to this mail with your vote.
Happy voting,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 28 Jan 2006, Ben Collins-Sussman wrote:
> Wow, our first vote-call... ever!
>
Are you sure?
http://svn.haxx.se/dev/archive-2003-12/1144.shtml
> I think this vote-call is premature though. There are at least four
> of us that are in favor of something more radical. Peter's ballot
> simply addresses the question of, "what should new code look like?"
> But Mike Pilato brought up the idea of reformatting *all existing*
> code in a single style, and then sticking to that forever:
>
I didn't read his mail that way before, but now I see that's completely
reasonable. But I'm fine with that as well.
...
> So I wonder if our flowchart should look like this:
>
>
> VOTE: Should *all* our code be one consistent style? Yes or no.
>
Yes, no, abstain, I guess.
> If "yes" ---> vote on the style. END.
>
foo(), foo (), abstain, right?
> Else if "no" --->
>
> VOTE: How should new code look?
>
>
>
The original ballot restarted in that case with three alternatives.
+1 on that plan. I'm willing to take care of this, wiht the first ballot
starting on Tuesday if no one objects.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by kf...@collab.net.
Molle Bestefich <mo...@gmail.com> writes:
> > and may make it harder to apply some currently outstanding patches.
>
> Fix 'svn merge' to optionally try and ignore whitespace differences :-)...
>
> Sorry if I'm just being an annoyance by advocating the obvious.
That's actually the 'patch' program we're talking about, and it
already has such an option. Which is why I said only "harder"...
probably should have said "slightly less convenient".
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by Molle Bestefich <mo...@gmail.com>.
kfogel@collab.net wrote:
> remember that reformatting old code will affect 'svn blame' information
Fix 'svn blame' to (optionally perhaps but per default) ignore
whitespace changes..
> and may make it harder to apply some currently outstanding patches.
Fix 'svn merge' to optionally try and ignore whitespace differences :-)...
Sorry if I'm just being an annoyance by advocating the obvious.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by Jim Blandy <ji...@red-bean.com>.
On 1/30/06, Peter N. Lundblad <pe...@famlundblad.se> wrote:
> On Sun, 29 Jan 2006 kfogel@collab.net wrote:
>
> > Ben Collins-Sussman <su...@red-bean.com> writes:
> > > Wow, our first vote-call... ever!
> >
> > Actually, we voted on whether to call the command-line client "svn" or
> > "sub", years ago.
> >
> Aha, cool to know:-) I wonder what we'd have called svnversion then...
The real story is, Jim Blandy had his heart set on "sub" and everyone
else, to a man, thought "sub" was way too ambiguous and "svn" was much
better. But I was so stubborn they had to have a vote to shut me up.
:) (I like 'svn' fine now.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 29 Jan 2006 kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@red-bean.com> writes:
> > Wow, our first vote-call... ever!
>
> Actually, we voted on whether to call the command-line client "svn" or
> "sub", years ago.
>
Aha, cool to know:-) I wonder what we'd have called svnversion then...
> Folks, remember that reformatting old code will affect 'svn blame'
> information, and may make it harder to apply some currently
> outstanding patches. I'm not saying these issues should be decisive,
> just wanted to make sure everyone was aware of them before voting.
>
This applies, more or less, to other sweeping changes we've had before
like replacing all printf calls with svnistic variants or replacing
SVN_REVNUM_T_FMT (or whatever) with "%ld". Maybe it is better to do this
once and for all. The drawbacks are mostly shortterm.
Starting new ballot tomorrow,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting
Posted by Julian Foad <ju...@btopenworld.com>.
Vincent Lefevre wrote:
> On 2006-01-29 08:37:12 -0600, kfogel@collab.net wrote:
>
>>Folks, remember that reformatting old code will affect 'svn blame'
>>information, and may make it harder to apply some currently
>>outstanding patches. I'm not saying these issues should be decisive,
>>just wanted to make sure everyone was aware of them before voting.
>
> Concerning 'svn blame', is this a good reason? I've noticed that
> there is the same problem when the indentation must be changed
> (e.g. because a 'if' is added...). IMHO, 'svn blame' should have
> an option to be space-insensitive (possibly depending of where
> the space occurs -- and this could depend on the svn:mime-type
> value).
+1 on the concept that this is a problem for "blame" to overcome. Whether it's
as easy as just adding an "ignore spaces" option is another matter, but it
might be that easy.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-01-30 18:31:57 +0100, Sander Striker wrote:
> Yes, but ofcourse people are going to mix formmating fixes and code
> changes in one revision in practice. Even in this project, where people
> are very strict about that; consider the example of adding an if {}
> block which requires reindenting. So I would be -1 on adding a
> hack like svn:blame-transparent as a general feature.
I completely agree.
On 2006-01-30 14:26:01 -0500, twall wrote:
> Given an "ignore-X" feature, does it make sense to hard-code it to
> whitespace or could it easily be extended to be any regular
> expression? I'm thinking of some files like this:
>
> <file path="xyzzy" modified="12pm EST"/>
> <file path="xyzzy" modified="5pm GMT"/>
>
> Where I want to effectively do 's/modified=".*"/modified=""/' prior
> to the diff.
I'd like that too, if possible. But this is less important. BTW, is
"svn diff" treated in the same way as "svn blame"?
[OT: Sorry for the bounces that could occur a few hours ago. It was
another bug in my procmailrc, but I'm going to write a procmailrc
checker, that will be called in a pre-commit hook, of course!]
--
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: svn blame and code reformatting
Posted by John Peacock <jp...@rowman.com>.
Peter N. Lundblad wrote:
> People have asked for it for ignore patterns. I guess we sometimes will
> have to depend on such a thing.
Then we can take this [narrow] use-case as another bullet point for the
reasons for a adding a full regex engine. I'm just trying to emphasize
that regex engine support is a very big deal that has to be approached
with much fear and trepidation (can you say stack overflow?)...
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: svn blame and code reformatting
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 30 Jan 2006, John Peacock wrote:
> twall wrote:
> > Given an "ignore-X" feature, does it make sense to hard-code it to whitespace or
> > could it easily be extended to be any regular expression? I'm thinking of some
> > files like this:
> >
> > <file path="xyzzy" modified="12pm EST"/>
> > <file path="xyzzy" modified="5pm GMT"/>
> >
> > Where I want to effectively do 's/modified=".*"/modified=""/' prior to the diff.
>
> Is it really so hard to ignore the one line that the above should
> display for each file so affected? Subversion does not currently
> require _any_ regex engine (the current code has a very limited '*'
> matching algorithm). I don't think this use-case is important enough to
> justify pulling in a cross-platform regex engine (which is really a very
> specialize state machine in its own language), though libpcre is very
> fine (and builds on Windows, FWIW).
>
People have asked for it for ignore patterns. I guess we sometimes will
have to depend on such a thing.
> One thing I glossed over is that although GNU's diff supports
> --ignore-space-change and --ignore-all-space, it does so from strictly a
> Latin-1 understanding of whitespace (tab, vtab, and space, I believe).
> Subversion is Unicode internally, so there is a much fatter target (does
> Subversion even support the Unicode Property Lists?). There was a
> certain amount of handwaving involved in my proposal... ;-)
>
Nope. We only assume files use an encoding equal to ASCII for the first
128 characters or so; we support only the ASCII line endings.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting
Posted by John Peacock <jp...@rowman.com>.
twall wrote:
> Given an "ignore-X" feature, does it make sense to hard-code it to whitespace or
> could it easily be extended to be any regular expression? I'm thinking of some
> files like this:
>
> <file path="xyzzy" modified="12pm EST"/>
> <file path="xyzzy" modified="5pm GMT"/>
>
> Where I want to effectively do 's/modified=".*"/modified=""/' prior to the diff.
Is it really so hard to ignore the one line that the above should
display for each file so affected? Subversion does not currently
require _any_ regex engine (the current code has a very limited '*'
matching algorithm). I don't think this use-case is important enough to
justify pulling in a cross-platform regex engine (which is really a very
specialize state machine in its own language), though libpcre is very
fine (and builds on Windows, FWIW).
One thing I glossed over is that although GNU's diff supports
--ignore-space-change and --ignore-all-space, it does so from strictly a
Latin-1 understanding of whitespace (tab, vtab, and space, I believe).
Subversion is Unicode internally, so there is a much fatter target (does
Subversion even support the Unicode Property Lists?). There was a
certain amount of handwaving involved in my proposal... ;-)
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: svn blame and code reformatting
Posted by twall <tw...@oculustech.com>.
> On 1/30/06, John Peacock <jp...@rowman.com> wrote:
> > Unfortunately, I think the most appropriate fix is to implement diff's
> > --ignore-whitespace feature (which would be useful in general for other
> > reasons) then allow blame to respect that when generating the blame
> > report...
>
Given an "ignore-X" feature, does it make sense to hard-code it to whitespace or
could it easily be extended to be any regular expression? I'm thinking of some
files like this:
<file path="xyzzy" modified="12pm EST"/>
<file path="xyzzy" modified="5pm GMT"/>
Where I want to effectively do 's/modified=".*"/modified=""/' prior to the diff.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 1/30/06, John Peacock <jp...@rowman.com> wrote:
> Unfortunately, I think the most appropriate fix is to implement diff's
> --ignore-whitespace feature (which would be useful in general for other
> reasons) then allow blame to respect that when generating the blame
> report...
+1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting
Posted by John Peacock <jp...@rowman.com>.
Sander Striker wrote:
> Even in this project, where people are very strict about that;
> consider the example of adding an if {} block which requires
> reindenting. So I would be -1 on adding a hack like
> svn:blame-transparent as a general feature.
Karl seems to be suggesting an ephemeral property (one that applied to
that revision only), so it could be used to say "this *specific* rev
shouldn't be used for blame purposes." If you had a mixed commit (code
and whitespace) then you simply wouldn't set the property for that
revision. The complication is that svn:blame-transparent would have to
set up to be multivalued, since there might be an instance where more
than one revision might need to be ignored.
Unfortunately, I think the most appropriate fix is to implement diff's
--ignore-whitespace feature (which would be useful in general for other
reasons) then allow blame to respect that when generating the blame
report...
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: svn blame and code reformatting
Posted by Sander Striker <st...@apache.org>.
kfogel@collab.net wrote:
> Vincent Lefevre <vi...@vinc17.org> writes:
>
>>On 2006-01-29 08:37:12 -0600, kfogel@collab.net wrote:
>>
>>>Folks, remember that reformatting old code will affect 'svn blame'
>>>information, and may make it harder to apply some currently
>>>outstanding patches. I'm not saying these issues should be decisive,
>>>just wanted to make sure everyone was aware of them before voting.
>>
>>Concerning 'svn blame', is this a good reason? I've noticed that
>>there is the same problem when the indentation must be changed
>>(e.g. because a 'if' is added...). IMHO, 'svn blame' should have
>>an option to be space-insensitive (possibly depending of where
>>the space occurs -- and this could depend on the svn:mime-type
>>value).
>
>
> I gave this some thought once, and came to the tentative conclusion
> that it's not trivial to implement.
>
> Actually, what I was thinking of was an 'svn:blame-transparent'
> revision property, that would cause that revision to be "transparent"
> to 'svn blame'. This way one could commit formatting fixes in their
> own revision, and have that revision not affect the blame information.
Yes, but ofcourse people are going to mix formmating fixes and code
changes in one revision in practice. Even in this project, where people
are very strict about that; consider the example of adding an if {}
block which requires reindenting. So I would be -1 on adding a
hack like svn:blame-transparent as a general feature.
> It was only when I started thinking about what this would actually
> mean, in concrete terms, that it started to get slippery... But if you
> (or someone) can figure out a way to do it, +1 :-).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn blame and code reformatting (was: [VOTE] space before paren policy)
Posted by kf...@collab.net.
Vincent Lefevre <vi...@vinc17.org> writes:
> On 2006-01-29 08:37:12 -0600, kfogel@collab.net wrote:
> > Folks, remember that reformatting old code will affect 'svn blame'
> > information, and may make it harder to apply some currently
> > outstanding patches. I'm not saying these issues should be decisive,
> > just wanted to make sure everyone was aware of them before voting.
>
> Concerning 'svn blame', is this a good reason? I've noticed that
> there is the same problem when the indentation must be changed
> (e.g. because a 'if' is added...). IMHO, 'svn blame' should have
> an option to be space-insensitive (possibly depending of where
> the space occurs -- and this could depend on the svn:mime-type
> value).
I gave this some thought once, and came to the tentative conclusion
that it's not trivial to implement.
Actually, what I was thinking of was an 'svn:blame-transparent'
revision property, that would cause that revision to be "transparent"
to 'svn blame'. This way one could commit formatting fixes in their
own revision, and have that revision not affect the blame information.
It was only when I started thinking about what this would actually
mean, in concrete terms, that it started to get slippery... But if you
(or someone) can figure out a way to do it, +1 :-).
-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
svn blame and code reformatting (was: [VOTE] space before paren policy)
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2006-01-29 08:37:12 -0600, kfogel@collab.net wrote:
> Folks, remember that reformatting old code will affect 'svn blame'
> information, and may make it harder to apply some currently
> outstanding patches. I'm not saying these issues should be decisive,
> just wanted to make sure everyone was aware of them before voting.
Concerning 'svn blame', is this a good reason? I've noticed that
there is the same problem when the indentation must be changed
(e.g. because a 'if' is added...). IMHO, 'svn blame' should have
an option to be space-insensitive (possibly depending of where
the space occurs -- and this could depend on the svn:mime-type
value).
--
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: [VOTE] space before paren policy
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@red-bean.com> writes:
> Wow, our first vote-call... ever!
Actually, we voted on whether to call the command-line client "svn" or
"sub", years ago.
On the function-call formatting issue: I'm waiting for Peter's new
ballot, which will include options about whether to reformat existing
code, before voting.
Folks, remember that reformatting old code will affect 'svn blame'
information, and may make it harder to apply some currently
outstanding patches. I'm not saying these issues should be decisive,
just wanted to make sure everyone was aware of them before voting.
Waiting for new ballot,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Wow, our first vote-call... ever!
I think this vote-call is premature though. There are at least four
of us that are in favor of something more radical. Peter's ballot
simply addresses the question of, "what should new code look like?"
But Mike Pilato brought up the idea of reformatting *all existing*
code in a single style, and then sticking to that forever:
"Consistency within a library caters only to the few folks whose
changes are only every to a single library. Those who tackled
problems of any magnitude are going to find themselves working in
multiple libraries, and there goes your consistency...
I'm with the folks that say consistency across the whole of the
application -- regardless of which style gets chosen as the Golden One
(though I personally much prefer space-before-paren) -- trumps the
half-hearted-yet-wholly-annoying existing policy."
Erik Huelsmann then replied:
"I'm very much +1 on one consistent style throughout the entire
application. If that means we don't do space-before-paren, that'll be
fine with me."
And then John Peacock said:
"Having been one of the [non-core] people trying to make changes
across multiple libraries (and getting burned because of it), I'm also
with "JUST PICK SOMETHING!" crowd."
So I wonder if our flowchart should look like this:
VOTE: Should *all* our code be one consistent style? Yes or no.
If "yes" ---> vote on the style. END.
Else if "no" --->
VOTE: How should new code look?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by Michael Sinz <Mi...@sinz.org>.
-1 -0 +0 +1 Alternative
[X] [ ] [ ] [ ] space-before-paren
[ ] [ ] [ ] [X] no-space-before-paren
[ ] [ ] [X] [ ] big-compromise
Justification - not that it matters - parens are part of the method/function
syntax. I also like having it more obvious that the parens are "arguments"
and not just grouping/expression holders.
(for example, I strongly want spaces before parens on if/while/for/switch/etc)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [VOTE] space before paren policy
Posted by Ivan Zhakov <ch...@gmail.com>.
Hi, Peter!
-1 -0 +0 +1 Alternative
[ ] [ ] [ ] [X] space-before-paren
[X] [ ] [ ] [ ] no-space-before-paren
[X] [ ] [ ] [ ] big-compromise
Justification:
I am strongly against "big-compromise" rule. In short: "when in Rome
do as the Romans do".
I consider that whole project should be consistent and have one style.
Because project is clear scope. In other words: I am always know when
I writing code for subversion, but I can forget for which module. Karl
Fogel already posted stats about current major style, so I consider we
should use it.
--
Ivan Zhakov