svn commit: r331461 - in user/markj/netdump/sys: kern netinet/netdump sys vm

[Rodney W. Grimes]

> On Saturday, March 24, 2018 08:40:24 AM Rodney W. Grimes wrote:
> > > On Sat, Mar 24, 2018 at 02:17:02PM +0200, Andriy Gapon wrote:
> > > > On 24/03/2018 04:46, Rodney W. Grimes wrote:
> > > > > I know this is on a private branch, but when/if it
> > > > > is merged this becomes part of the main line.
> > > > 
> > > > Not with svn, I think.
> > > > At least, the way we use it.
> > > 
> > > Indeed, I have no intention to merge the branch directly. I'm using an
> > > svn branch so that it's marginally easier for others to test.
> > 
> > None the less as stated in:
> > 	https://svnweb.freebsd.org/base/projects/GUIDELINES.txt?view=markup
> > 
> > 12 	General guidelines:
> > 13 	
> > 14 	* Should be relevant to FreeBSD.
> > 15 	* Should be at least conceivably of interest to somebody else.
> > 16 	* Should be in a format that is suitable to merge into the base tree.
> > 17 	* Should be something that is worth people's time to read commit mail for.
> > 18 	* Write decent commit messages!
> > 
> > Thanks,
> 
> We generally don't do that for user, etc. branches.  Merging from a
> projects/user branch into head in svn is often a disaster due to svn's
> limitations, so normally a projects/user branch is treated as a work area
> and the resulting diff is then hand-applied to head with a suitable commit
> message that describes the entire change.  This is similar to using something
> like 'git rebase' to rewrite history and compress a long tail of changes
> down to a small number of commits prior to merging to head.

I was quoting from a document that is specifically addressing "user and
project" branches.   It seems we have a conflict of opionion on this.


> You generally don't see these work branches in svn as most developers do them
> outside of svn in git, p4, hg, etc. due to svn's limitations.
> 
> For things that live permanently in user/projects (e.g. the code for core
> elections or the patches for freebsd-update), we do want standard commit
> messages.  However, I don't think we want to impose that on WIP branches
> that are later compressed down before merging.

Then why bother mailing them to @committers and having us all read
through them.  I am sure that was Peters intent when he wrote this
guideline.

And as far as I am aware all things in user/projects are permanent,
and globally mirrored.

-- 
Rod Grimes                                                 rgrimes at freebsd.org