It's being worked on at this very moment. I implements a forth solution: - update.bat sense if svn/python is already installed (with nifty trick), and only "install" its own copy if not found.
Also, I removing the linux/mac/win branches in depot_tools. I should check-in the first draft tomorrow. M-A On Thu, Apr 23, 2009 at 12:21 PM, Erik Kay <[email protected]> wrote: > > I think this is still an issue. We also have a similar issue with the > python in depot_tools vs. the one in third_party vs. the one in cygwin > and local system for mac and linux (different versions and different > built-in modules for each of them). If we're going to depend on > depot_tools versions, then we need to have a way to explicitly > reference those versions from our scripts. The problem is that since > depot_tools are installed independently, there's no current way to get > to where they're installed from the chromium tree. > > Possible solutions: > - require another environment variable when installing depot_tools > (DEPOT_TOOLS_PATH) > - add a script in the depot_tools bin directory that simply emits the > path to the bin directory > - add a script to chromium_dev that searches your PATH for the > location of gcl/gclient, etc. > > I'm not really a fan of any of these. Anybody have another suggestion? > > Erik > > > On Wed, Apr 22, 2009 at 11:13 PM, Darin Fisher <[email protected]> wrote: >> IIRC, some people (peter?) have had /usr/bin/svn on their path ahead of >> depot_tools, since they don't want our svn interfering with their webkit >> checkout. this used to work if you always accessed our svn by calling gvn >> instead (yes, i meant gvn). i believe that gcl, like gvn, will also pass >> through to svn, but when i try it now, i get a strange error. so, perhaps >> no one is counting on this anymore. >> -darin >> >> On Wed, Apr 22, 2009 at 9:58 PM, Mark Larson (Google) <[email protected]> >> wrote: >>> >>> I filed http://bugs.chromium.org/10872 for this... >>> >>> From src/chrome/tools/build/win/version.bat: >>> :: Determine the current repository revision number >>> set PATH=%~dp0..\..\..\..\third_party\svn;%PATH% >>> svn.exe info | grep.exe "Revision:" | cut -d" " -f2- | sed "s/\(.*\)/set >>> LASTCHANGE=\1/" >> %VarsBat% >>> call %VarsBat% >>> This calls trunk/deps/third-party/svn/svn.exe, which is not the same >>> version as svn in depot_tools. >>> Result? >>> Generating version template file >>> svn: This client is too old to work with working copy '.'. You need >>> to get a newer Subversion client, or to downgrade this working copy. >>> See http://subversion.tigris.org/faq.html#working-copy-format-change >>> for details. >>> >>> >>> My preference would be to remove svn from the tree. We require you to use >>> gclient to pull the tree, so you already have svn in one place. If it's >>> not >>> in your path, I think it's OK for this step to fail (modify the bat file >>> to >>> point to your copy of svn). >>> For most users and the buildbots, svn will be in the path. >>> So just calling 'svn' means version.bat will use the same version that >>> gclient used to check out the files. >>> Any objections to >>> 1. Pulling deps/third_party/svn out of the tree? >>> 2. Changing version.bat to just call 'svn' (expecting it in the path)? >>> >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
