I am working on a number of projects simultaneously. Each project has a Subversion repository. The repositories are not all hosted on the same server. When I start my day, I find myself having to do an svn update for each of the individual projects.
My local working copies are all stored under one parent directory Projects.
My question: Is there a command that can be issued from the Projects directory that will search for working copies among the descendants in the file system and issue an svn update command for each of them?
I'm on Ubuntu with Subversion version 1.7.5.
cd to Projects and then:
svn up `ls -d ./*`
(note those are backticks, not single quotes.)
svn will happily skip non-svn dirs.
You could add an alias in your .bashrc
alias up-svn='svn up `ls -d ./*`'
You could just write
svn update *
That's it... Subversion will automatically recognize the working copies and do the update
One more suggestion similar to #thekbb answer
svn up `find ~/svn -maxdepth 3 -type d`
Explanation:
'~/svn' is my directory all checked out repositories are in
'-maxdepth 3' some repositories are nested (3 levels deep)
e.g. companyname/projectname/branch
'-type d' only directories
no, but you can easily write a script/batch file that calls "svn update" on each subdirectory.
Related
I'm working on a python project and want to rename a (package) folder to small letters, let's say from Myackage to mypackage. As git is case-sensitive and Windows is not, I followed the solutions taken from here and espacially here.
My procedure was as follows:
git mv Mypackage tmp
git mv tmp mypackage
git commit -m "Change capitalization of package name"
This changes the folder Myackage to mypackage with success (for both, git and Windows). But if I switch to another branch, I expect the folder to change back to Mypackage (with capital letter!), as it was before. Background is, that all the imports of the package are also case-sensitve in python and i need this renamng acompanied with adaptions of the imports.
I've tried both, core.ignorecase set to true and false, but no matter what I try, if I checkout an older branch, the folder remains in form of small letters (mypackage) and I run into issues within python.
UPDATE:
I've set up a small example with only one Folder and one file and could succesfully change the capitalization of the folder. It also shows the desired behaviour, that upon branch switch the capitalization of the folder in Windows changes, yet still this won't work for my python project.
Could it be, that, e.g., submodules, play a role here?
UPDATE 2:
I've checked the case sensitivity attribute for both cases via:
fsutil.exe file queryCaseSensitiveInfo .
Both folders claim, that case-sensitivity is deactivated. Still for one project folder name capitalization changes, but for the other folder not.
The attribute case sensitivity is available on Windows 10 but after April 2018 Update and only affect the specific folder to which you apply it. It isn’t automatically inherited by that folder’s subfolders. However, if you use WSL to create folders it's enabled by default and available in that way to Windows. [1]
Although you can use the Git Unite [2] tool to match the case of the current folders with the git index.
If you use the rename approach, try using it with git commands like in "Rename files and folders with git"[3]
git mv foldername tempname && git mv tempname folderName
I found a way to reproduce your behavior :
if my CaSeD folder contains some extra files (untracked files for example), git will not change the case of my folder name when I jump between commits.
Is this the case in your setup ?
If this is your issue : you could go with a post-checkout hook, which forcibly renames the folders according to what is stored in HEAD after a checkout.
One way to get the full list of paths to directories from commit HEAD is :
git ls-tree --name-only -d -r HEAD
If you match this list with a similar list extracted from your local file system (ls -r ? find . -type d ? some python function from os.* ?), you can spot what folders need to be recapitalized.
I'm working in a very large project. I need to perform a search in all pom.xml files under a trunk folder (I've a hundred different trunk folder) in order to find if it contains a certain dependency.
I can't donwload all the svn repository, so I need to make a remote search. Is there a efficient way to do it ?
I think I should locate trunk folders, then search all pom.xml files into them before grep'ing their content to find my dependency, but I don't know how to do it on remote server :/
svn ls -R in the root of tree, grep needed files, construct full URL
svn cat URL/OF/FILE | grep PATTERN for each file
Use a combination of Find and Grep command. Similar to (not exact)
grep -R "192.168.1.5" /etc/
or with combination with Find command
find . -name “*.xml” |xargs grep -n “bla”
see here
i have been sent a directory tree of source code that i want to import into my subversion repository. The issue is that at some point this code was in a different subversion repository. There are a huge number of directories and subdirectories and i basically want to clean up all of the subversion .svn folders before i attempt to import to a new repository and i dont want svn to get confused.
is there anyway to clean out a directory structure to remove all svn references?
svn export will produce a copy of the source tree without the .svn folders. Example:
svn export <old_project_root> <new_name_of_clean_directory>
I believe TortoiseSVN also has this capability from within a menu.
In the root of the project, with GNU find:
find . -name .svn -execdir rm -r {} +
EDIT: Corrected, with thanks to rkulla. -delete does not -delete non-empty directories.
Stefan, author of TortoiseSVN, has a complete explanation here. The gist of it is to use a built-in TortoiseSvn right-click helper to do the job like so:
(source: tortoisesvn.net)
For more possible solutions see the following question ‘Un-SVN’ a working copy.
One answer contains a Windows batch script that will cleanup all .svn folders.
This question already has answers here:
How to make git ignore changes in case?
(6 answers)
Closed 10 months ago.
There are a couple of files in our git-controlled codebase that I'd like to rename. Specifically, I just want to change the case of the file, so that sourceCode.java becomes SourceCode.java, for example. The catch: I'm on a Windows box, and the filesystem thinks those are the same file name.
How can I get Windows and Git to recognize that change and check it in?
The change of the file name should not be ignored, but committed to git.
To rename the file you can use the standard git mv command.
Since Windows treats files with only changes in case as identical, you have to pass the -f option to force a rename:
git mv -f name.java Name.java
If instead you want to ignore case changes, have a look at the question
How to make git ignore changes in case?.
If you are on a FAT file system your only choice is to do a two stage rename:
Rename sourceCode.java to anything.you.like
Rename anything.you.like to SourceCode.java
Back in the days when we used Perforce we had exactly this problem and this was the only solution we could come up with.
The following steps allowed me to change the case on Windows:
Add ignorecase = false to [core] in .git/config;
Move the files you are going to rename out of your project directory;
Add the deletes to the index;
Move all files back to their original location and change the case of the files and/or directories;
Add all "new" files to the index;
Remove ignorecase = false added at the first step.
This way you have a single commit that contains the rename and it makes it easy to change e.g. an entire directory.
In my opinion one simple way is missing. You can do this for a single file, a specific directory or even the whole repository. Just rename your files in any way you like before and than execute these commands:
git rm --cached <file name or directory>
git add <file name or directory>
If you want to affect also the sub-directories, you have to use the -r flag:
git rm -r --cached <directory>
git add <directory>
Be careful. Doing this can lead to changes that are impossible to merge. Git gets confused when merging on Windows because it can't decide whether the old Uppercase name and the new lowercase name are the same file or not (for Git they are not, but for the filesystem they are). To merge you have to do some manual workaround like deleting the files before merging.
See Git rebase issue with files of same name but different case
I'm not sure if this issue is worse than having an unconventionally-named file in your project for ever and ever, but it is worth knowing about if there are lots of users with lots of branches which will all need to be merged eventually.
With NTFS (or FAT), a single git mv command does not solve the problem.
This question shows a technique that works:
git mv and only change case of directory
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How do you remove Subversion control for a folder?
Command line to delete matching files and directories recursively
I recently converted my cvs repository to svn using cvs2svn and I recently noticed that every directory has a hidden folder called .svn. My current build script copies a lot of directories from my versioned resources directories and it ends up copying the .svn files. Is there anyway to make svn not include these files when I checkout or do I need to write a script to delete all these .svn files. There are many files that have these hidden .svn directories so this would be a pain unless I could write a recursive script to do this but I don't if I can do this for my windows installer. Is there an easy way to stop svn from putting this hidden directory everywhere in my project?
I'm not sure in your specific case that you want to remove all those .svn directories. But if you do, here is a bash one-liner to do just that:
find . -name .svn -print0 | xargs -0 rm -r
You can do a thing called an SVN Export to get the files without the .svn directories
http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html
I posted this yesterday over here, but here is again because I kind of put it in the wrong thread anyway...
I've got something that should make your day. Original source is here.
This is a (perfectly safe) Shell Extension that will add "Delete SVN Folders" to your right click menu in Windows. Run it on any directory containing those pesky files.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteSVN]
#="Delete SVN Folders"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\DeleteSVN\command]
#="cmd.exe /c \"TITLE Removing SVN Folders in %1 && COLOR 9A && FOR /r \"%1\" %%f IN (.svn) DO RD /s /q \"%%f\" \""
To make this part of your build script copy that call to cmd.exe and execute it.
find . -name '.svn' -depth -exec rm -rf '{}' \; -ls
on Win32/Win64 systems, the following command should do the job:
del /q /s .svn
Those folders are required for how subversion works with a working copy (i.e. where you've done a checkout).
One option would be for you to do an export to another location. The export would not have the .svn folders, and you could run your script on that. Documentation: svn export, TortoiseSVN Export
Another option would be to modify your script to ignore hidden directories, or build a better build tool.
And a PowerShell version
ls -Force -Recurse -Filter .svn | rm -Force -Recurse
svn export is what you want. It will give you a clean copy of the code tree without the .svn directories (note that this copy is not under version control and svn commands won't work on it once it's exported).
I utilize this method to launch code on production servers. Our build script takes an export of the code branch, tars and gzips it, uploads it to the correct server, and unzips/untars it.
If wanna do this with ruby just paste my script at the root folder you want to remove recursively: http://fabianosoriani.wordpress.com/2009/03/19/ruby-script-to-remove-svn-folders/
You could take a look at SVK, which is a layer on top of Subversion. One of the advantages is that the repository metadata for your working copy, which is normally stored in the .svn dirs, is instead kept in a single central location, so you don't have the ugly hidden .svn dir problem. It's pretty nice.
find "/YourFolder" -name ".svn" -exec rm -fdR {} \;
Check this
link
I dont know if I would delete them, but maybe modify your build script to ignore copying them would be a good idea. I use Ant to build compile and build my war and it does so ignoring .svn dirs.