Let's back up a moment. What I want is that GWT releases should self-identify the source code they came from. My first cut at this defined a "release" as anything coming off of our auto-build stuff, which meant that I just declared that svn identification would come in from the "outside world" (that is, whatever launches the top-level ant) as an ant property.
This means that as developers work, they would naturally and lazily not define the property, and so their builds would be [EMAIL PROTECTED] or the like. Since those aren't "releases" (and likely aren't a pure checkout on avny svn revision anyway), I didn't care about that... but Scott's review of that first cut wanted the version-detection internalized, which requires a dependency on something that can get the svn version, in tools and/or in gwt. We can add svnkit to "tools." We've already added my SvnInfo task (I did actually look at some pre-existing svn tasks, some of which used svnkit, but they either didn't work for me or didn't get the degree of information I wanted). But I'd almost rather re-make the pitch for my first solution: does it matter if Joe's personal build is just "unknown"? On Thu, Sep 25, 2008 at 11:43 PM, Kelly Norton <[EMAIL PROTECTED]> wrote: > FWIW, the fact that the build now assumes that the svn on your path is the > one that created the working directory causes build breaks on my machine. I > don't know if this is something that we want to deal with, but adding calls > to svn does introduce another environmental assumption. SVNKit is a java > based svn1.5 lib that could free us from having to depend on the svn > executable (assuming there are no licensing issues). > http://svnkit.com/ > > /kel > > On Thu, Sep 25, 2008 at 11:22 PM, Freeland Abbott < > [EMAIL PROTECTED]> wrote: > >> Here's the patch, Alex... sorry. The first-cut at this branding was >> careful about "what if they don't have it," but used <propertyregex> which >> was unhappy on ant 1.6.5; the second task implementation wasn't (but should >> have been) so careful. >> (@Scott, by the way, to answer a prior questoin, I did look at the ant >> Execute.java stuff... I wasn't convinced it added much for a >> non-daemon-style process, and it'd require either moving the task into tools >> as a binary and/or putting the ant sources into tools so we'd have them to >> compile against. I wasn't convinced that was a better answer than my >> runCommand()) >> >> >> >> On Thu, Sep 25, 2008 at 9:35 PM, Freeland Abbott <[EMAIL PROTECTED]>wrote: >> >>> Mm. That'll be my rework to get ant 1.6.5 back in the game; I should >>> allow those execution failures (with resulting svn branding of >>> [EMAIL PROTECTED])... >>> >>> >>> On Thu, Sep 25, 2008 at 6:34 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote: >>> >>>> >>>> I was trying to build the trunk on my windows install -- I didn't have >>>> the command line version of svn, just tortoise, and I got the message >>>> "cannot launch command svn info", referencing line 208 of >>>> common.ant.xml. If we require particular svn tools for the build, >>>> should we write that down somewhere in the README file for Eclipse? Or >>>> maybe somewhere else in the docs? >>>> >>>> -- >>>> Alex Rudnick >>>> swe, gwt, atl >>>> >>>> >>>> >>> >> >> >> > > > -- > If you received this communication by mistake, you are entitled to one free > ice cream cone on me. Simply print out this email including all relevant > SMTP headers and present them at my desk to claim your creamy treat. We'll > have a laugh at my emailing incompetence, and play a game of ping pong. > (offer may not be valid in all States). > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
