asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <>
Subject Re: Integrating the folder change and package change into topic branches
Date Wed, 26 Aug 2015 14:48:54 GMT
In addition to Ian's posting: I would like to share my experience. I have
updated the master branch and my branch and I saw this happening. After you
do two git merges (one - the path renaming, the other - the package
rename), Eclipse might complain about the ADMLexer and ADMDataParser and
shows a lot of errors. In this case, you just need to manually create a new
package named "org.apache.asterix.runtime.operators.file.adm" in the
"target/generated-sources" of the "asterix-runtime" project and put file and file there. The two files are
located in the "org.apache/asterix/runtime/operators/file/adm" directory in
the "target/generated-sources" of the "asterix-runtime" project.


On Tue, Aug 25, 2015 at 9:31 AM, Ian Maxon <> wrote:

> Hi all,
> With the last few patches that have been submitted, integrating them back
> into all of our open topic branches may be a little more complex than
> usual.
> In the simplest case, if you have a change that doesn't add .java files nor
> edit import or package statements, 'git gerrit update' should just work
> without complaint or conflict. If you do have changes of that type, 'git
> gerrit update' will still work, but you'll have to resolve the rebase
> conflict.
> If you use merge typically instead of 'git gerrit update' or rebase to pull
> in new changes, you should take extra caution. Just a plain 'git merge'
> will most likely create many ugly conflicts when it attempts to merge both
> the path renaming change, and the package renaming change, at once. The
> work around for this is to merge them one at a time (e.g. in asterix, git
> merge 34d8163 for the path renaming change, and git merge f18bba26 for the
> package rename). In the first step you'll have to move any java files you
> created with a folder under edu/uci/ics to org/apache, and in the second
> resolve all the conflicts related to imports and package naming. If in the
> last step there are a lot of conflicts, sometimes it is easier to merge
> while taking your local changes first, and then re-doing the package change
> from edu.uci.ics to org.apache with sed on the affected files, instead of
> trying to resolve them all one by one.
> In short, you run into a really bad merge conflict,  please don't hesitate
> to ask for advice about it here. Hopefully the above advice is helpful, but
> every situation is unique.
> Thanks,
> -Ian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message