eGit does the trick for me. I have no desire to dive down to the command line for something the IDE can do :-) I have a limited amount of brain bucket and I'm not filling it up with CLI flags if I can help it. That's just me tho.
Ramsey On Apr 1, 2013, at 11:52 AM, Dan Beatty wrote: > So Pascal, Ramsey, and fellow members of the Wonder gang, > If I were to teach a course and should need recommendations for the way to > teach and learn Git; what packages, books, online references, etc would you > recommend as a kind of training wheels for said students? Also, if I were > to produce an iBook and its Android equivalent form of our WO book with > clips from the the tutorials, what all would I need to do it? > > V/R, > > Daniel Beatty, Ph.D. > Computer Scientist, Detonation Sciences Branch > Code 474300D > 1 Administration Circle M/S 1109 > China Lake, CA 93555 > [email protected] > (LandLine) (760)939-7097 > (iPhone) (806)438-6620 > > > > > On 4/1/13 11:27 AM, "Pascal Robert" <[email protected]> wrote: > >> > Le 2013-04-01 à 13:02, Ramsey Gurley <[email protected]> a écrit : > >> I >> merged the fix to the master and integration branches. As far as I can tell, >> I've got everything done except pushing the tag on master. It just wasn't in >> my push configuration. I can try again when I get home tonight. >> >> As for >> releasing other integration changes, I tend to use eGit for everything. Is >> there anything in that command line magic which wouldn't happen if I just >> make >> a local branch at a9426 and merged that into master? > > I don't use eGit anymore >> for commits or branching, I use it only to check the history in Eclipse or to >> see the status of the files. For preparing a release of Wonder, I always did >> it by command line. For everything else, I use SourceTree. > >> Ramsey >> >> On >> Apr 1, 2013, at 9:44 AM, Pascal Robert wrote: >> >>> In that case, do a real >> 6.0.3 release >>> >>> Switch into the master branch >>> >>> Check the Git >> history of the integration branch and note the last commit that should be >> integrated into master (a9426b5ed8a806b6a7292209f8783416bce1a046 is a good >> candidate for 6.0.3). >>> >>> Do a merge with the commit id of the previous >> step: git merge -s recursive -Xpatience -Xtheirs XXXXXX >>> >>> Push the >> release candidate to GitHub: git push origin master >>> >>> Tag the merge >> with a "wonder-6.x.x" tag: >>> >>> git tag -a wonder-6.x.x >>> git push >> --tags >>> >>>> And evidently, I didn't configure my push to push the new 6.0.3 >> tag :P >>>> >>>> Anyway, try the latest master Freddie and see if your problem >> goes away. >>>> >>>> Ramsey >>>> >>>> On Mar 30, 2013, at 3:17 PM, Ramsey Gurley >> wrote: >>>> >>>>> >>>>> On Mar 30, 2013, at 11:18 AM, Ramsey Gurley wrote: >>>>> >> >>>>>> >>>>>> On Mar 29, 2013, at 3:37 PM, Ramsey Gurley wrote: >>>>>> >>>>>>> >> On Mar 29, 2013, at 2:27 PM, Freddie Tilley wrote: >>>>>>> >>>>>>>> at >> er.modern.directtoweb.components.header.ERMD2WSimpleHeader.headerString(ERMD2W >> SimpleHeader.java:25) >>>>>>>> >>>>>>> >>>>>>> My wonder says that line >> is: >>>>>>> >>>>>>> return >> stringValueForBinding(Keys.displayNameForPageConfiguration); >>>>>>> >>>>>>> >> What is your rule for displayNameForPageConfiguration? It doesn't look like >> your stack trace goes through ERDDefaultDisplayNameAssignment. >>>>>>> >>>>>>> >> Kieran, >>>>>>> >>>>>>> This also looks like a bug in wonder. ERXGenericRecord >> doesn't handle a null editingContext() in handleQueryForUnboundKey(). That's >> going to be the case on deleted objects. >>>>>>> >>>>>>> I think that should >> just check entity().primaryKeyAttributeNames().contains(key) first. That >> method is called a lot and there's no reason to be building pk dictionaries >> every time. This shouldn't wait for the next integration merge. >>>>>>> >>>>>>> >> Ramsey >>>>>> >>>>>> Hmm, even calling entity() repeatedly is going to add >> overhead. Adding a private static >>>>> >>>>> er.. transient :P Can't be static >> since every eo would share the same entity. >>>>> >>>>>> entity var may be >> needed to cache the EOEntity and prevent constantly searching through the >> models :-/ The other problem I see is that entity() may result in null when >> there's no ec and the entity is not in the default model group. Not sure how >> often that happens. >>>>>> >>>>>> I'm thinking this method should look >> something like to prevent the NPE: >>>>>> >>>>>> public Object >> handleQueryWithUnboundKey(String key) { >>>>>> // Handles primary key >> attribute values >>>>>> if(entity().primaryKeyAttributeNames().contains(key)) >> { >>>>>> // Deleted object. Return null. >>>>>> if(editingContext() == null) >> { >>>>>> return null; >>>>>> } >>>>>> NSDictionary pkDict = >> EOUtilities.primaryKeyForObject(editingContext(), this); >>>>>> // New >> object. Return null. >>>>>> if(pkDict == null) { >>>>>> return null; >>>>>> >> } >>>>>> // Return value for key >>>>>> return >> pkDict.objectForKey(key); >>>>>> } >>>>>> return >> super.handleQueryWithUnboundKey(key); >>>>>> } >>>>>> >>>>>> Alternately, is >> this something that we could simply remove and put into an eogen template for >> anyone who needs this? The more I look at this the less I like it. This >> method >> is going to get called a ton for any ERD2W app that uses object.someKey in >> rules. >>>>>> >>>>>> In my ERUsers framework I have >>>>>> >>>>>> 55 : >> (pageConfiguration = 'CreateERUser' and propertyKey = 'clearPassword' and >> object.password.length > 0) => componentName = "R2D2WPropertyMessage" >> [com.webobjects.directtoweb.Assignment] >>>>>> >>>>>> Which means the current >> method is called and creating a pkDict for every single property level >> component on every single page that isn't an ERUser. I just tested it on a >> ListMovie page. On a ten item page, handleQueryWithUnboundKey is called 960 >> times. >>>>> >>>>> Also, I obviously need to change the way I'm doing >> componentName here because even creating 960 UnknownKeyExceptions is just >> excessive. >>>>> >>>>>> This is not good. This method needs to be very fast or >> it needs to be removed. >>>>>> >>>>>> Ramsey >>>>>> >>>>> >>>>> >> _______________________________________________ >>>>> Do not post admin >> requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list >> ([email protected]) >>>>> Help/Unsubscribe/Update your >> Subscription: >>>>> >> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.c >> om >>>>> >>>>> This email sent to [email protected] >>>> >>>> >> _______________________________________________ >>>> Do not post admin requests >> to the list. They will be ignored. >>>> Webobjects-dev mailing list >> ([email protected]) >>>> Help/Unsubscribe/Update your >> Subscription: >>>> >> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca>>> >> >>>> This email sent to [email protected] >>> >> > > > >> _______________________________________________ > Do not post admin requests to >> the list. They will be ignored. > Webobjects-dev mailing list >> ([email protected]) > Help/Unsubscribe/Update your >> Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/daniel.be >> atty%40navy.mil > > This email sent to [email protected] > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
