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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>wrote: >> >>> >>> On Tue, Jan 13, 2009 at 4:10 PM, gregor <[email protected]> >>> 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 -~----------~----~----~----~------~----~------~--~---
