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 -~----------~----~----~----~------~----~------~--~---
