On Wed, 2011-12-28 at 14:09:10 -0800, Doug Barton wrote:
> On 12/28/2011 07:40, Ulrich Spörlein wrote:
> > On Mon, 2011-12-26 at 01:14:28 -0800, Doug Barton wrote:
> >> On 12/26/2011 01:07, Xin LI wrote:
> >>> Author: delphij
> >>> Date: Mon Dec 26 09:07:08 2011
> >>> New Revision: 228896
> >>> URL: http://svn.freebsd.org/changeset/base/228896
> >>>
> >>> Log:
> >>>   Merge from OpenBSD 5.0 (this is a dummy change, the vendor change does 
> >>> not
> >>>   apply to us).
> >>
> >> When I'm importing stat(1) stuff from Net/OpenBSD I don't do this. I
> >> will however comment in the commit log for the next substantive change,
> >> "Skipped update N.NN because the change was not relevant to us," or
> >> words to that effect.
> >>
> >> I'm not suggesting that my way of doing this is perfect, or cannot be
> >> improved. I would suggest however that this change was needless churn.
> > 
> > I think it was the right thing to do. It's better to have one person
> > (Xin LI) figure out if the change is needed or a no-op and do the
> > upgrade to match our version to upstream's version, than to have a
> > discrepancy between the two and cause half a dozen developers that
> > stumble upon that difference to scratch their heads and spend time in
> > figuring out if we should import the change.
> 
> Fair enough. Having thought more about this my only remaining concern is
> that by slipping the tag we're misrepresenting the status quo since
> what's in our tree is not really that version of the file. Perhaps a
> comment to the effect of "purposely skipping version 1.23 because ..."
> would be better?

I always look at the CVS Ids from other projects as some kind of
guideline or high water mark as to when someone has last looked at all
the upstream changes and possibly brought over all the changes that
apply. I mean the files are never guaranteed to be the *exact* revision
1.23 from OpenBSD, due to FreeBSD specific changes. Should every committer
changing a file look for CVS Ids of other projects and then remove them
as the file is being altered and no longer matches upstream bit for bit?

That surely is impractical, of course no one would propose such a
scheme. Adding that information to the commit message is prudent,
however. In the end, whoever gets shit done is getting shit done :)

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

Reply via email to