[vtk-developers] Strange repo happenings with vtkOpenGLProjectedTetrahedraMapper

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Dec 22 15:34:24 EST 2011


Gerrit is now upgraded with the topic review functionality too. That
will make things easier, requiring the developer to rebase if their
topic will not merge cleanly will give us the opportunity to review
the outcome of their conflict resolution.

On Thu, Dec 22, 2011 at 3:32 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> That could work. We can require ParaView developers to get their
> changes into VTK through gerrit too, and that would be totally
> acceptable on the ParaView side as well.
>
> Utkarsh
>
> On Thu, Dec 22, 2011 at 3:25 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I think we should require all changes to go through gerrit. I'm sure I
>> would have caught this conflict.
>>
>>
>> On Thu, Dec 22, 2011 at 3:20 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> On Thu, Dec 22, 2011 at 3:15 PM, Utkarsh Ayachit
>>> <utkarsh.ayachit at kitware.com> wrote:
>>>> On Thu, Dec 22, 2011 at 2:35 PM, David Cole <david.cole at kitware.com> wrote:
>>>>> On Thu, Dec 22, 2011 at 1:59 PM, Brad King <brad.king at kitware.com> wrote:
>>>>>> On 12/22/2011 8:42 AM, Bill Lorensen wrote:
>>>>>>>
>>>>>>> If I do a git log on the vtkOpenGLProjectedTetrahedraMappe.cxx file I
>>>>>>> don't see your commits or mine.
>>>>>>
>>>>>>
>>>>>> The other part of this thread identified the vtkstd changes.
>>>>>> I'll follow up with why your commit (49c1f9de) is not shown by:
>>>>>>
>>>>>>  $ git log 49c1f9de~1..31ec9251 -- \
>>>>>>   VolumeRendering/vtkOpenGLProjectedTetrahedraMapper.cxx
>>>>>>
>>>>>> The command tells Git to start at commit 31ec9251 and walk back looking
>>>>>> for commits that change the given file.  When Git comes to the incorrect
>>>>>> merge commit 174c39e8 it sees that the file in the commit is identical
>>>>>> to one of its parents.  Therefore it assumes that the content in the file
>>>>>> as of the merge commit can be fully explained by the history of the one
>>>>>> parent in which it is identical.  It follows only that parent and prunes
>>>>>> out the history from the other parent.  Your commit only appears in the
>>>>>> pruned side of history so it gets skipped.
>>>>>>
>>>>>> The above behavior is an optimization that does the right thing in the
>>>>>> case that merges were done correctly.  One can use the "--full-history"
>>>>>> option to disable the behavior.  The following command shows your commit:
>>>>>>
>>>>>>  $ git log 49c1f9de~1..31ec9251 --full-history -- \
>>>>>>   VolumeRendering/vtkOpenGLProjectedTetrahedraMapper.cxx
>>>>>>
>>>>> This whole day, and this whole discussion, points out one shortcoming
>>>>> of our current workflow. I'm not saying there's a good way to fix it,
>>>>> but am "just saying":
>>>>>
>>>>> The shortcoming is the combination of:
>>>>> - having some commits that are "sweeping changes" that touch lots and
>>>>> lots of files
>>>>> - also allowing merge commits surrounding those sweeping changes
>>>>> - also allowing topic branches that are based on very old (more than a
>>>>> couple weeks or so?) commits in 'master'
>>>>> - having developers resolve conflicts (the human error factor)
>>>>>
>>>>> The problem is mainly that sweeping changes that touch lots of files
>>>>> are time-consuming to review. And yet, if there are many outstanding
>>>>> topic branches, it is likely that those sweeping changes will be
>>>>> merged in over and over again (because others are touching some of the
>>>>> same files). The more that happens, the more the "I've seen this
>>>>> already" response the developer has, ... making mistakes during
>>>>> conflict resolution more likely.
>>>>>
>>>>> We don't have a good way to detect "mistaken conflict resolutions" --
>>>>> other than the next day's dashboard -- and, in some cases like this
>>>>> one, it's very difficult to tell what happened after the fact.
>>>>> Thankfully, we've at least discovered the --full-history flag to make
>>>>> future analyses easier.
>>>>>
>>>>> I wonder if there's a way to add more eyes to the "conflict resolution
>>>>> by a developer" process such that this becomes less likely. Perhaps a
>>>>> 2nd pair of eyes on a manual conflict resolution in this case would
>>>>> have caught the mistake before it was merged into master.
>>>>>
>>>>> One other thing we could do to help make sweeping changes easier is to
>>>>> make them on an agreed upon day, and then have everybody rebase
>>>>> outstanding topic branches on 'master' again as soon as the sweeping
>>>>> changes are in.
>>>>>
>>>>> Of the two, I think "more eyes" is the more important point.
>>>>
>>>> I totally agree with "sweeping changes" statement. I have been burnt
>>>> by it far too often. Another problem with sweeping changes is doing
>>>> them in the same commit. That precludes cherry-picking which can help
>>>> solve any conflicts.
>>>
>>> We still need a mechanism, as these things are required at times. I
>>> think the vtkstd removal was one such occasion, but perhaps
>>> distributing the load among developers by asking them to rebase their
>>> topics would be better. Many projects simply refuse to merge topics
>>> with conflicts and ask the author to rebase them, having three
>>> integration branches for VTK doesn't make things easy either...
>>>
>>> Marcus
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com



More information about the vtk-developers mailing list