Re: CVS commit: src/sys/arch/x86/x86

On Dec 8,  4:04pm, perrypiermont.com ("Perry
E. Metzger") wrote:
-- Subject: Re: CVS commit: src/sys/arch/x86/x86

| 
| christosastron.com (Christos Zoulas) writes:
| > Perry E. Metzger <perrypiermont.com> wrote:
| >>
| >>matthew green <mrgeterna.com.au> wrote:
| >>>    Is there any good reason not to just
change it to __func__ in all of
| >>>    these? If not, I'll just do it.
| >>>
| >>> code churn while many branches are in the
process of being merged.
| >>> please don't do this.
| >>
| >>When do you think a better time would be? (The
diffs are trivial,
| >>btw.)
| >
| > I think after vmlocking2, jmcneill_pm, mjf_devfs are
merged. I guess that
| > would be sometime in January?
| 
| Okay.
| 
| Alternatively, it would be pretty easy to apply the diffs
to those
| branches at the same time. I imagine that would serve the
same
| purpose? (The changes are quite straightforward, and I
could patch the
| three branches as well as the head without any trouble.)

If you want to patch head and re-sync the branches (not
patch the branches,
because this does not help much), get permission from the
branch owners and
do it...

christos

christoszoulas.com (Christos Zoulas) writes:
> | Okay.
> | 
> | Alternatively, it would be pretty easy to apply the
diffs to those
> | branches at the same time. I imagine that would serve
the same
> | purpose? (The changes are quite straightforward, and
I could patch the
> | three branches as well as the head without any
trouble.)
>
> If you want to patch head and re-sync the branches (not
patch the branches,
> because this does not help much), get permission from
the branch owners and
> do it...

I don't quite get the difference -- can you explain? I would
have
thought that if I performed the same transformation on both
the trunk
and the branch it would eliminate any incremental merge
effort the
change imposed. CVS doesn't keep track of change sets, after
all...

-- 
Perry E. Metzger		perrypiermont.com

On Sat, Dec 08, 2007 at 06:20:17PM -0500, Perry E. Metzger
wrote:
> 
> christoszoulas.com (Christos Zoulas) writes:
> > | Okay.
> > | 
> > | Alternatively, it would be pretty easy to apply
the diffs to those
> > | branches at the same time. I imagine that would
serve the same
> > | purpose? (The changes are quite straightforward,
and I could patch the
> > | three branches as well as the head without any
trouble.)
> >
> > If you want to patch head and re-sync the branches
(not patch the branches,
> > because this does not help much), get permission
from the branch owners and
> > do it...
> 
> I don't quite get the difference -- can you explain? I
would have
> thought that if I performed the same transformation on
both the trunk
> and the branch it would eliminate any incremental merge
effort the
> change imposed. CVS doesn't keep track of change sets,
after all...

If you change a line which also has an unrelated change in
the branch,
this will cause a conflict when the branch is merged. Even
if you make the
same change in the branch and in HEAD.

Pavel

Pavel Cahyna <pavelnetbsd.org> writes:
> If you change a line which also has an unrelated change
in the branch,
> this will cause a conflict when the branch is merged.
Even if you make the
> same change in the branch and in HEAD.

If the merge system works as expected, then why is there a
problem in
the first place?

There are about 400 lines of diff I'm going to create, in a
code base
of millions of lines. Given the size of the differences
between the
branches and the head, and assuming that the changes I'm
making are
uncorrelated with them (which seems reasonable), I'm
guessing this
means the people doing merges will end up with a handful of
trivial
conflicts each to deal with at most -- and given all the
changes
everyone else makes every day, it is an almost ignorable
level of
trouble.

Why bother with branches if it is a problem to change a
trivial
percentage of the codebase on the head?


Perry