Create a new working copy by cloning a subtree of an existing working copy?
With SVN 1.7, is there a way to create a new working copy by cloning a subtree of an existing working copy? For example: - Already checked out: wc1/ wc1/.svn wc1/src wc1/data wc1/data/bin1 - Desired: a new working copy of just the "data/" subtree: wc2/ wc2/.svn wc2/bin1 A reason of doing this could be to improve performance. Thanks, Kuno
Re: Create a new working copy by cloning a subtree of an existing working copy?
Stefan Podskubka hcs.at> writes: > On 20.12.2011 15:44, Kuno Meyer wrote: > > With SVN 1.7, is there a way to create a new working copy by cloning a > > subtree of an existing working copy? > > > One thing that comes to mind is cloning the existing working copy and > then performing an svn switch to the subtree. > > However, I don't know exactly how the switch is done and if it performs > better than a fresh checkout. I suppose it does, since all the files and > pristines are already in the existing checkout. Thanks. Unfortunately, in my case, cloning the whole working copy (3.5 GB, 60k files) before stripping it down is similarly expensive to re-checking out the subdirectory (150 resp. 300 MB, 5 files each), despite of the somewhat limited network bandwidth.
Re: Create a new working copy by cloning a subtree of an existing working copy?
Mark Phippard gmail.com> writes: > > With SVN 1.7, is there a way to create a new working copy by cloning a > > subtree of an existing working copy? > > > > See: > http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py Thanks. My tests show that the prominently placed comment "This script is unfinished and not ready to be used on live data. Trust us." is indeed true. My feedback: 1) There are Windows filesystem issues: os.path.* converts most paths to backslashes, whereas wc.db expects forward slashes. In addition, things fail badly (and much too late) if casing is incorrect. 2) The elimination of unneeded pristines didn't seem to work for me, I always ended up with a full clone of the /.svn/pristine folder. However, it might be that 'migrate_pristines()' is similarly prone to the Windows filesystem issues (in path comparisions and string matching) like 'migrate_sqlite()', where I had do some hackish changes. As conclusion, I fear that 'detach.py' is not in a state ready for us to be used in production environment, and that I have to fall back to some other caching mechanism. Regards, Kuno
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
Another unconventional way of accomplishing this would be to use Bazaar's clean-tree command. With the bzr-svn plugin installed, you should be able to directly operate on SVN working trees: bzr clean-tree --ignored --unknown --detritus --force
'svn cleanup' ignores externals
Is it by design that 'svn cleanup' ignores externals and that there is no way to include them? I found it a bit inconsistent that 'working copy' has different meanings for 'svn update' and 'svn cleanup'. Kuno $>svn help update update (up): Bring changes from the repository into the working copy. $>svn help cleanup cleanup: Recursively clean up the working copy, removing locks, resuming $> svn up Fetching external item into '': svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted At revision 62460. svn: E205011: Failure occurred processing one or more externals definitions $> svn cleanup $> svn up Fetching external item into '': svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted At revision 62460. svn: E205011: Failure occurred processing one or more externals definitions
Re: 'svn cleanup' ignores externals
Daniel Shahaf wrote on Mon, 16 Apr 2012 14:48:45 +0300: > Kuno Meyer wrote on Mon, Apr 16, 2012 at 10:31:33 +: > > Is it by design that 'svn cleanup' ignores externals and that there is > no way to > > include them? > > > > You should be able to include them by naming them explicitly: > > % svn cleanup path/to/external/dir Thanks. This is what I did. However, since I am not the one who set up the "externals" layout of our source code repository, it took me some time to understand the way a working copy containing external references is organized. And then again, I realized that my custom update and rebuild script fails at garbage collecting unreferenced pristines in sub-WCs included by "externals" defnitions. But that's another story... Kuno -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
