John raises an important issue when doing
automatic merges (no matter the source control system), but it should be noted
that there are well known techniques for doing auto merges safely. As a point
of reference, we have recently successfully implemented the “auto merge
agent” pattern in Oracle Eclipse Tooling team. It helps us juggle many
branches (with complex merge relationships between them) without a lot of
manual and tedious work required from the devs.
Essentially an auto merge agent is a
script that sits in a loop and polls the source control system for changes to
integrate. It picks the first change (in order) and runs it through the merge
process… merge… resolve… build… test. If it gets to the
end of the process, it commits the change to the target branch. If the process
fails, the agent gathers the relevant info and sends an e-mail to the dev team.
I then waits for the change to be manually merged before continuing. Rinse and
repeat.
It turns out that the vast majority of
changes can be integrated safely this way with zero manual steps required. One
of the reasons that this is the case is that the automated agent will likely attempt
the merge very soon after the original change goes in. This minimizes the
potential for conflicting changes to build up.
We are using Perforce for source control,
but the auto merge agent pattern is applicable to any system that has ability
to group file changes into atomic change lists and has support for auto merge /
resolve algorithms. Will not work with CVS.
- Konstantin
From:
e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Thursday, March 12, 2009
10:32 AM
To: E4 Project developer mailing
list
Subject: Re: [e4-dev] Resources
6-Mar-2009 meeting notes
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
No
virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.11/1997 - Release Date: 03/12/09
10:38:00
