Re: svn commit: r289664 - head/sys/kern

[Anton Yuzhaninov]

On 10/20/15 23:42, Bryan Drewery wrote:

On 10/20/2015 1:38 PM, Konstantin Belousov wrote:

Author: kib
Date: Tue Oct 20 20:38:20 2015
New Revision: 289664
URL: https://svnweb.freebsd.org/changeset/base/289664

Log:
   Trim spaces at end of line to record the proper commit message for
   r289660:


I really think we should just do a full revert and recommit in these
cases, and not even a forced commit.  Neither this commit or a forced
commit will show in 'svn blame' or even during a bisect.  It really just
becomes luck to find the right commit noting the message.  IMHO 'svn
blame' is more important than some extra churn in 'svn log' or email. It
does add more steps in 'svn blame' but it ends up giving the right
message more obviously.

I'm not asking to redo this commit now, but I think we should have a
standard of just recommitting to fix mistakes.


Why
svn propedit svn:log --revprop -r289660
Is not used?
AFAIR this was disabled, because revprop edit can't be synced with CVS. But 
there is no official CVS repo for a log time.

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r289664 - head/sys/kern

[Bryan Drewery]

On 10/20/2015 1:38 PM, Konstantin Belousov wrote:
> Author: kib
> Date: Tue Oct 20 20:38:20 2015
> New Revision: 289664
> URL: https://svnweb.freebsd.org/changeset/base/289664
> 
> Log:
>   Trim spaces at end of line to record the proper commit message for
>   r289660:
>   
>   Do not allow to execute ptrace(PT_TRACE_ME) when the process is
>   already traced.
>   
>   Do not allow to execute ptrace(PT_TRACE_ME) when there is no parent
>   which can trace the process, i.e. when the parent is already init.
>   Note that after the PT_TRACE_ME request the process is unkillable and
>   non-continuable until a debugger is attached, or parent is killed, the
>   later clears P_TRACED state.  Since init clearly would not debug the
>   caller, and cannot be killed, disallow creation of unkillable
>   processes.
>   
>   Reviewed by:jhb, pho
>   Reported and tested by: pho
>   Sponsored by:   The FreeBSD Foundation
>   MFC after:  2 weeks
>   Differential revision:  https://reviews.freebsd.org/D3908
> 
> Modified:
>   head/sys/kern/sys_process.c
> 
> Modified: head/sys/kern/sys_process.c
> ==
> --- head/sys/kern/sys_process.c   Tue Oct 20 20:37:00 2015
> (r289663)
> +++ head/sys/kern/sys_process.c   Tue Oct 20 20:38:20 2015
> (r289664)
> @@ -443,7 +443,7 @@ ptrace_vm_entry(struct thread *td, struc
>  }
>  
>  #ifdef COMPAT_FREEBSD32
> -static int  
> +static int
>  ptrace_vm_entry32(struct thread *td, struct proc *p,
>  struct ptrace_vm_entry32 *pve32)
>  {
> 

I really think we should just do a full revert and recommit in these
cases, and not even a forced commit.  Neither this commit or a forced
commit will show in 'svn blame' or even during a bisect.  It really just
becomes luck to find the right commit noting the message.  IMHO 'svn
blame' is more important than some extra churn in 'svn log' or email. It
does add more steps in 'svn blame' but it ends up giving the right
message more obviously.

I'm not asking to redo this commit now, but I think we should have a
standard of just recommitting to fix mistakes.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r289664 - head/sys/kern

[Ed Maste]

On 20 October 2015 at 16:42, Bryan Drewery  wrote:
>
> I really think we should just do a full revert and recommit in these
> cases, and not even a forced commit.  Neither this commit or a forced
> commit will show in 'svn blame' or even during a bisect.  It really just
> becomes luck to find the right commit noting the message.  IMHO 'svn
> blame' is more important than some extra churn in 'svn log' or email. It
> does add more steps in 'svn blame' but it ends up giving the right
> message more obviously.
>
> I'm not asking to redo this commit now, but I think we should have a
> standard of just recommitting to fix mistakes.

This is the approach taken by LLVM and it works well there. You're
right that it introduces a bit of churn but I think it's worth the
cost.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"