Re: [e4-dev] Resources 6-Mar-2009 meeting notes

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Sorry, I think I misunderstood what
you were suggesting. If git or some other tool can help us create the merge
patches easily, that would be helpful. We can then review and apply the
patches manually if desired.

John

James Blackburn <jamesblackburn@xxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

03/12/2009 01:55 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Resources 6-Mar-2009 meeting notes

John you're completely right, and I agree with you! 

A textual merge which happens to build needn't work as
a result of semantic api changes. However if the semantics of some api
change one would hope the developer would notify the list and or commit
equivalent fixed into e4 as well as head. 

If they don't, yes things will break, simple as that.
The problem is unless the person who does the merge knows of these changes
in advance, they too might miss this.

I was only offering to help, what youve said makes it
sound like there is no automatic solution to this nor should we try to
invent one. If thats the case, then ok its no skin off my back.

However I thought that if we merge more frequently such
breakage would be rare, and be discovered and fixed more quickly. If the
integration touches 90 files the chance of breakage is that much higher.

At the end of the day the merge patch needs to be reviewed.
The mechanism I've proposed is for generating that patch painlessly, not
for proving the patch doesn't introduce bugs. 

Cheers

James   

On 12 Mar 2009, at 17:31, John Arthorne <John_Arthorne@xxxxxxxxxx>
wrote:


At the risk of turning this into DVCS holy war, it's an overly simplistic
assumption to believe that just because changes are in separate files or
separate methods, that they can be merged automatically without reviewing
them. To give a very simple example, say the fork removes a non-API method
and fixes every reference to that method accordingly. Meanwhile a different
class in the mainline adds a new reference to that method. The merge can
happen automatically because the changes are in different classes, but
the merged result won't compile. There are many more example of this that
are far more subtle (think of non-API method contract changes). What you
are essentially saying is that you can perform a complex merge with GIT
using three commands, and only browsing three source files. If you're lucky
this will compile without errors, but there is a good chance of errors
from conflicting changes between the two branches (not conflicting source
code locations, but conflicting conceptual/contract/assumption changes).
This kind of merging might be good enough to allow someone to quickly hack
away on a branch, but when we're talking about merging branches to create
product-quality releases, I think there is no substitute for reviewing
the changes one by one. 

John

James Blackburn <jamesblackburn@xxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

03/11/2009 08:33 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Resources 6-Mar-2009 meeting notes

Hi Mike,

2009/3/6 Mike Wilson <Mike_Wilson@xxxxxxxxxx>:
> (And no, switching to <insert your favorite repo here> won't
fix the problem.)

Well you say that, and until recently I would probably have agreed
with you.  However I think using a DVCS, designed for each user having
their own (multiple) branches (with frequent branch merging), is
almost a silver bullet. Why?

1) The DVCS knows the fork point. It knows which commit caused the
first deviation of e4 from HEAD.
2) The DVCS deals with patchsets. All commits within n minutes by the
same committer with the same commit message are treated as an atomic
commit
3) The DVCS has clever (5 in gits case) merge algorithms.  When
applying patches manually you need to cope with changes already
applied, files moving, etc.
4) The DVCS automates the process.  You type 3 commands (including
creating the repository!) and resolve the merge conflicts: clone,
branch, merge: http://wiki.eclipse.org/Git_for_Committers#Merging_HEAD_changes_to_e4
5) When the automatic merge fails (and it seems to work pretty well:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=268107#c12
) the DVCS
has commands to quickly show you the relevant commits which changed
that file.

So in this case I'm using git. org.eclipse.ui.ide had quite a few
files touched in both repos. Most conflicts were handled
automatically. There were 5 merge failures, 3 were trivial, and 2 were
real code changes.  The best bit: I only typed 3 git commands, and
only had to look at 5 source files!  Git even displayed the diffs
from
the conflicting commits and the associated commit comment so I could
quickly jump to bugzilla to see what why the changes were made.

I know it's easy to be a DVCS fan-boy, point and say "it's new &
shiny
therefore better". But I wonder how else would you do it?  diff
and
patch?  It might be worth having a go and seeing if at the end of
the
process you only have to merge 5 files.

I'm a new convert to git, and still have nightmares of the merge pain
I experienced when pulling upstream changes into our internal fork.
The merge process was really hard and very error prone.  git has
changed that by putting all the commands you need for pulling, pushing
and merging patchets into one tool.  Clearly the tool isn't magic.
But the point of using the DVCS is that you can leverage someone
else's work and use something that has been designed and well-tested
for performing just these operations.

I'd be interested to know if you manage to merge HEAD and e4 more
quickly using a method other than git!
(Commands oultined on the wiki:
http://wiki.eclipse.org/Git_for_Committers#Merging_HEAD_changes_to_e4
)

Cheers,

James

>
> McQ.
>
> Szymon Brandys ---06/03/2009 12:39:19---Martin, My only concern about
moving
> CNF to e4 resources repo is that some part of
>
>
> From:
> Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>
> To:
> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
> Date:
> 06/03/2009 12:39
> Subject:
> Re: [e4-dev] Resources 6-Mar-2009 meeting notes
> ________________________________
>
>
> Martin,
>
> My only concern about moving CNF to e4 resources repo is that some
part of
> UI
> will be developed in two different places, e.i. e4 ui and e4 resources.
> Wouldn't there be a problem with syncing them in the future?
>
> Regards
> --
> Szymon Brandys
>
>
>
>
>             "Oberhuber,
>             Martin"
>             <Martin.Oberhuber  
                     
                 To
>             @windriver.com>  
        "E4 Project developer mailing list"
>             Sent by:      
           <e4-dev@xxxxxxxxxxx>
>             e4-dev-bounces@ec  
                     
                 cc
>             lipse.org
>                    
                     
                     
  Subject
>                    
                  [e4-dev]
Resources 6-Mar-2009
>             2009-03-06 18:11  
       meeting notes
>
>
>             Please respond to
>                E4 Project
>             developer mailing
>                   list
>             <e4-dev@eclipse.o
>                    rg>
>
>
>
>
>
>
> Hi all,]
>
> notes of the meeting we just had are now online:
> http://wiki.eclipse.org/E4/Resources/Meeting/6-Mar-2009
>
> James, Serge please review if I got the "Linked Resources"
discussion right
> and edit the Wiki if not.
>
> New Action Items
>      Szymon add background info on bug 253705 support
for branched file
>      systems
>      James create a Wiki page with simple instructions
how to get git up
>      and running as a committer
>      (Embedded image moved to file: pic32596.gif)Image:Ok_green.gifMartin
>      to ask on e4-dev for cloning CNF into e4 repository
as soon as
>      possible (John to do it?)
>      Martin to ask Ken Ryall about his action items
>      (Embedded image moved to file: pic30558.gif)Image:Ok_green.gifMartin,
>      Serge to CC on bugzilla e4.resources-inbox@xxxxxxxxxxx
(using
>      bugzilla preferences)
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
> [attachment "pic32596.gif" deleted by Mike Wilson/Ottawa/IBM]
[attachment
> "pic30558.gif" deleted by Mike Wilson/Ottawa/IBM]
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev