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 <dragonsi...@gmail.com> 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 < > jor...@jordanzimmerman.com> 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 ( >> mckenzie....@gmail.com) 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 < >> jor...@jordanzimmerman.com> wrote: >> >> > Great work. Thank you. >> > >> > ==================== >> > Jordan Zimmerman >> > >> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dragonsi...@gmail.com> >> 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 >> > >> > >
