[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
How exactly does the svninfo task contribute to the build? I'm still getting a gwt-windows-0.0.0 directory as output. Would be nice to have a revision number there instead. On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com wrote: I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
I see that the rev number is inserted into About.properties. It would be nice if this also appeared in the output directory name. Having gwt.version = 0.0.0 isn't very useful. It's a bit annoying to look for the rev number and manually rename the directory after every build. On Jan 18, 6:42 pm, Alex Epshteyn alexander.epsht...@gmail.com wrote: How exactly does the svninfo task contribute to the build? I'm still getting a gwt-windows-0.0.0 directory as output. Would be nice to have a revision number there instead. On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com wrote: I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
There's a difference between the release number (e.g. 1.5.3 for a release, or 0.0.0 for an arbitrary desk build) and the SVN revision of the sources (which might, accounting for branches and mutation, be something like 1...@4327:4364M). The SVN version is burned into About.properties, About.txt, and About.html; it's given in the help output, and primarily helps with bug reports: I saw wacky behavior X, using SVNrel... On Sun, Jan 18, 2009 at 6:42 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: How exactly does the svninfo task contribute to the build? I'm still getting a gwt-windows-0.0.0 directory as output. Would be nice to have a revision number there instead. On Jan 12, 11:00 pm, Freeland Abbott gwt.team.fabb...@gmail.com wrote: I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
FWIW, I use the cygwin version of svn on windows. Works just like Unix! Of course, Tortoise is a great graphical client for Windows. On Tue, Jan 13, 2009 at 9:03 AM, gregor greg.power...@googlemail.comwrote: Yes, that's what I eventually did. I chose the CollabNet svn command line client option for which I had to sign up for an account. I didn't originally want to do that, but it became apparent that CollabNet has close connections to the Subversion project itself, so I became less averse. I think you might be able to use the zip download options marked Apache 2.0 and Apache 2.2, but that I believe involves installing the subversion server as well as the command line client. Installing the CollabNet client worked a treat, and it still works this morning. On Jan 13, 3:25 am, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've usedhttp://www.sliksvn.com/en/downloadbefore. Ian -- Eric Z. Ayers - GWT Team - Atlanta, GA USA http://code.google.com/webtoolkit/ --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
Freeland, I believe there is a Java SVN frontend that will gracefully degrade through: 1) Your installed svn libraries through JNI 2) Command line svn 3) SvnKit Would that make this option less repulsive? On Mon, Jan 12, 2009 at 11:00 PM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've used http://www.sliksvn.com/en/download before. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
Repulsive is a strong word, but yes, I like it better as more able to avoid mismatches in an otherwise functional development environment. But they'd still be possible, so would we eventually be having the same discussion anyway? (In particular, I think knorton has said he edits common.xml to neuter the test because he has multiple svn version installed, and always gets the wrong one on his path... does this help him, or is he just beyond help with that tangle?) In which case, is my suggestion of weak error checking unless -Dgwt.releasebuilder=true be as functional, easier, and safe? On Tue, Jan 13, 2009 at 10:51 AM, Scott Blum sco...@google.com wrote: Freeland, I believe there is a Java SVN frontend that will gracefully degrade through: 1) Your installed svn libraries through JNI 2) Command line svn 3) SvnKit Would that make this option less repulsive? On Mon, Jan 12, 2009 at 11:00 PM, Freeland Abbott gwt.team.fabb...@gmail.com wrote: I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.comwrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've used http://www.sliksvn.com/en/download before. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
Use the tigris (apache 2.0 / apache 2.2) binaries - they don't actually require (or contain) apache ... http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 Get the zip (last download link on the page) and add the bin folder to your path. S --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
Just install a recent svn client, it shouldn't interfere. Freeland, we could also consider either making the successful execution of this task optional, or even check SVNKit into TOOLS and using that to power the Ant task. On Mon, Jan 12, 2009 at 1:16 PM, gregor greg.power...@googlemail.comwrote: I'm trying to make a 1.6 build from trunk to test 1.6 and I got hit with this which seems to emanate from macrodef name=gwt.getsvninfo task in common.ant.xml. I use Tortoisesvn and I gather that it doesn't qualify as a command line svn client and this is the problem. Can I hack build.xml or common.ant.xml to get round this, or is there a recommended svn download (windows for me) that won't interfere with tortoise? regards gregor --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
FYI - it appears I'm not alone in this http://svn.haxx.se/users/archive-2008-10/0491.shtml On Jan 13, 12:11 am, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. I'm sure I'll find a solution, but I'd just comment that this a real nuisance, and I think either making the svn task optional or handling it via SVNKit sounds like a very good idea to me. On Jan 12, 8:08 pm, Scott Blum sco...@google.com wrote: Just install a recent svn client, it shouldn't interfere. Freeland, we could also consider either making the successful execution of this task optional, or even check SVNKit into TOOLS and using that to power the Ant task. On Mon, Jan 12, 2009 at 1:16 PM, gregor greg.power...@googlemail.comwrote: I'm trying to make a 1.6 build from trunk to test 1.6 and I got hit with this which seems to emanate from macrodef name=gwt.getsvninfo task in common.ant.xml. I use Tortoisesvn and I gather that it doesn't qualify as a command line svn client and this is the problem. Can I hack build.xml or common.ant.xml to get round this, or is there a recommended svn download (windows for me) that won't interfere with tortoise? regards gregor --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've used http://www.sliksvn.com/en/download before. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: C:\GWT_source\common.ant.xml:209: cannot launch command svn info
I've actually never had trouble getting a command-line client, but that's beside the point. We can make no svn and also not compatible messages be non-blocking errors, though as I mentioned that raises the question of whether anything should be blocking... and if not, whether we're getting anything out of branding desk builds anyway. (That is, should be make it optional, or remove it and let the build robot assert its value and everybody else not brand at all?) I'm negatively biased on SvnKit, mostly because of workspace compatibility: if I use whatever-I-like to create my workspace, it'd have to be compatible with the SvnKit from our tools checkout, right? At if SvnKit got over-eager to update my workspace, the other tool would then lose, yes? At least with, say, TortoiseSVN and my command-line svn, I got them both, know about them, and can see why the problem exists. I'm increasingly coming to think that all svninfo errors should be non-blocking, with a non-default property for the robot to instead say no, I really care. And that'd likely mean that only robot builds would have branding, in which case maybe we should just go there. On Mon, Jan 12, 2009 at 10:25 PM, Ian Petersen ispet...@gmail.com wrote: On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote: Well, finding a windows command line svn client looks easier said than done. I've spent over an hour now trying to find a free one (I've got no use for it at the moment apart from this issue), and it's not at all clear that there is one that will do the job without messing about with 30 day trials for Syncro and the like. Is there a reason you can't use one of the binaries listed here? http://subversion.tigris.org/getting.html#windows I'm pretty sure I've used http://www.sliksvn.com/en/download before. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
