On 11/26/13, Jiří Baum <j...@baum.com.au> wrote: > Jiří: >>> I need to rename 100,448 files in bzr, but running "bzr mv" 100,448 >>> times is taking too long. Anybody know if there's some sort of >>> multi-move? > > Zenaan: >> I only know git sorry. If there is any similarity, then some >> assumptions needs to be provided by you, eg how are the files >> structured (one directory, or multiple?), what depth of directories?, > > Various directories in a tree structure.
>> Perhaps figure a quick way in bash (with find or some such) and >> perhaps bzr can then auto-delete the "old" files and auto-add the >> "new" (renamed) files (ie, with a single bzr command).. > > Yeah, I'd prefer a rename rather than re-adding all the files. With > 100000 files adding up to 2G, it's worth doing it right. Ah ok, I remember now, git figures out renames implicitly, so in git this procedure would "just work" - I take it that's not the case in bzr, and so you are limited to using "bzr mv" if you want rename history to be kept. git appears to be superior in this case - the git mv's I've done (with or without using git mv, since it is genuinely implicit) have been almost flawless - and when flawless is required, I then make sure I do the mv in a separate commit to file content changes (this is usually not needed, only if you want to _guarantee_ that the rename will always be detected, which is in my own case, almost never needed). Good luck Zenaan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
