Cool. You should be able to just push a fix and then fast-foward CURATOR-3.0.
On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <[email protected]> wrote: > I think it's all good. I've fixed up the couple of build issues on the > 217-merged branch. Just running the unit tests. If everything's ok then > I'll merge it back into CURATOR-3.0 and then I think we're back in a stable > state, and I can start on CURATOR-214. > > On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <[email protected]> wrote: > >> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher path >> for getConfig()? >> >> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> Sorry - it’s hard to follow this thread. What do I need to do? >>> >>> -Jordan >>> >>> >>> >>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie ( >>> [email protected]) wrote: >>> >>> Thanks Scott, >>> I've just merged CURATOR-217 into master and have one small issue. >>> >>> Jordan, with the changes you made with to the Watching.java class, the >>> getWatcher() call now takes a CuratorFramework reference and a path >>> reference. >>> >>> The GetConfigBuilderImpl breaks when merging because it's using the old >>> getWatcher() call that doesn't exist any more. This isn't an issue to >>> fix, >>> but I'm just wondering what path reference should be used for the >>> configuration case, as it's a different sort of watch. It's just passed >>> to >>> the getConfig() call on the ZooKeeper class. It seems that I can't just >>> pass in a null path as this gets validated. Suggestions? >>> >>> cheers >>> >>> >>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman < >>> [email protected]> wrote: >>> >>> > Great work. Thank you. >>> > >>> > ==================== >>> > Jordan Zimmerman >>> > >>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <[email protected]> >>> wrote: >>> > > >>> > > This is now done, sorry for the delay. Let me describe the current >>> state >>> > > of the world: >>> > > >>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old, >>> > > CURATOR-3.0-temp - these are the old versions of all the branches, we >>> > > should consider pruning them at some point. >>> > > >>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased >>> versions >>> > of >>> > > the branches we should stick with. >>> > > >>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There is >>> nothing >>> > > that has been committed to master that isn't in 3.0 now. >>> > > >>> > > Procedures going forward: >>> > > >>> > > - If you're working on stuff for 2.8 / 2.9, branch from master and >>> > > merge/commit to master. >>> > > >>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0 and >>> > > merge/commit to CURATOR-3.0. >>> > > >>> > > - Periodically, we'll want to get master changes into 3.0. To do >>> this, >>> > *check >>> > > out CURATOR-3.0*, and merge master into that, then push the result >>> after >>> > > fixing conflicts (which should be small / non-existent). *Don't do it >>> > the >>> > > other way, don't check out master and merge 3.0 into it.* >>> > > >>> > > For discussion: there is a *3.0-rejects* branch. One of the commits >>> > there >>> > > is and added System.out.println that I think we don't want. The other >>> > one >>> > > is the work to migrate to fasterxml Jackson. I think we actually want >>> > this >>> > > commit on 3.0. Please take a look and let me know, if we want this >>> > commit, >>> > > we should cherry-pick it onto 3.0. I'm happy to do that. >>> > > >>> > > Everything I did should be reversible, so let me know if I screwed >>> > anything >>> > > up! >>> > > >>> > > --Scott >>> > >>> >> >> >
