"." directory has been committed to repo, need to remove it

Recently the '.' file within linux was committed to the repo.  I was thinking of running delete command but was worried about the ramifications of removing that file in linux.  svn delete .  My understanding of delete will be to remove it locally followed by scheduling for removal upon next commit.  I don't really want to remove the file as much as I want to remove the file from svn control.

Last updated 6 years ago

You should "cd .." and then remove the directory by name. Never a good thing to try to remove the directory that your process has as its current working directory (not a supported operation).  Also, please understand that what the "svn delete" operation does is to remove the name of the object (directory, file, symlink) from that revision. Prior revisions will still have that named object.  The only way to completely remove something from a Subversion repository is to "dump | filter | load" - which will pretty much make any existing working copy very unhappy.

Probably should have said that I am not that great at svn. My local version of the repo runs on windows with tortoise. The file/directory (.) has been committed already to the repo/branch and the dev sever, which is linux (and so was the developer's whom made the change, therefore the addition of . to the repo).  I don't/cannot remove the file/directory '.'. I would like to be able to keep the file/directory, everywhere, but remove that file from version control.  Hopefully that is clearer but understand if the answer is the same. I could just use more detail. Once again, excuse me being a novice at svn.

No worries about being an SVN novice.  The name "." for a directory is a way to display the "current" directory when "in" that directory. In the simplest example I can think of, you could do "dir c:\Users\." and it would produce a directory listing of the "c:\Users" directory. In other words, "c:\Users\." is the same as "c:\Users". Another simple way to think about this is to "cd c:\Users" and then "dir ." would produce a listing of the "c:\Users" directory.  Once a directory has been added to version control and you need to remove that directory then the proper command to use is, as you noted, "svn delete". But it should not be used on ".". Instead you should, as I noted above, "cd .." and then remove the directory by its proper name.  As far as keeping the directory in the working copy after the removal, I would zip up the directory contents before the removal, remove it, then put the directory tree back down again after the removal operation was complete. New working copies would need to find some way to populate that directory tree since it will not appear during/after the "svn checkout" (since it is no longer being version controlled). I say this because you've stated "I would like to be able to keep the file/directory everywhere but remove the file from version control." If this isn't what you had in mind, please try describing the situation again.

Thanks for the long description answer. It helps a ton, especially understanding '.'. I think we are close.  In my case, the placement of the '.' in the repo is at the base directory (repo is in /var/www/html and the issue is with '.' in /var/www/html). I would be removing the directory that the repo exists within. That seems like it may be problematic(?).  You stated: As far as keeping the directory in the working copy after the removal, I would zip up the directory contents before the removal, remove it, then put the directory tree back down again after the removal operation was complete.  Question: In my case, I would do the following: 1. zip up /var/www/html 2. remove /var/www/html 3. replace the zip file back in /var/www/  That doesn't seem like it would do anything but get me back to where I was at before?  Thank you again for your time, assistance and patience.

With Subversion there is the concept and implementation of the "repository" and there is the concept and implementation of the "working copy".  SVN repositories contain directory entries like "conf", "db", "format", "hooks", and "locks". Clearly those are not files or directories that I would expect to find in "/var/www/html". SVN repositories therefore should be kept somewhere else (e.g. like directory entries in a "c:\svndata\repos" directory).  SVN working copies contain directory entries that you might expect to find in "/var/www/html" but with an additional directory ".svn". In the ".svn" directory Subversion keeps all of the files that enable it to manage the working copy (Subversion private data). The rest of the tree is exactly what is needed for any specific project. Files, directories, symlinks (e.g. a directory tree of directory entries).  From your description, it appears that you are talking about a working copy (not a repository). If you no longer want the "/var/www/html" directory to be a working copy but want to leave the rest of the directory tree then simply remove the "/var/www/html/.svn" directory tree. It will then no longer be a working copy (and therefore no longer under version control).

Think I am lost again.  I don't want to get rid of the directory, just the '.' file. Below is the svn statemetn that shows the change (omitted the other files). This is from /home/www/html/ directory.  $ svn up U . Updated to revision 9066.  I have never seen '.' being updated.  Maybe it is fine to leave it. Maybe I am going in to so many different directions I can't keep stuff straight  Hopefully this helps to understand what I want to do. Maybe it isn't possible?

You can't get rid of "." - period. The "." is a directory artifact that says "this directory". If you have a directory then "." is always defined (your file system would be corrupt if the "." entry was not there).  That said, "." will get updated if someone goes into the root of a working copy and adds/removes a directory entry (i.e. a file, a directory, a symlink). Adds that change and checks it in. On next "svn update" the root directory of the working copy will get updated with that change.  

Getting back around to this. Since the '.' file has been showing up in the repo, there are owner/group changes to files in the .svn directory that causes updates via svn to be painful. I typically have to run "svn cleancache" a couple times surrounded by the normal svn command (today it was an svn revert that was sandwiched between two such calls).  I keep referring to it be an issue '.' but don't know if this is something else causing the changes. I just know I have difficulties since the '.' file started showing up as changed.   Any thoughts to what I could try an do?