I am working on a shared project which is put in SVN. The directory structure of the project is as follows:
ParentDir
- Child_Dir_1
+ GrandChild_Dir_1
+ GrandChild_Dir_2
- Child_Dir_2
Child_Dir_1 contains configuration files (Eclipse's .LAUNCH files), and people put all sorts of file in this folder.
So each time I update my source code (by right clicking on ParentDir and picking Update), I got a lot of configurations that I don't really need, and I have to delete them manually.
I still need to have the children of Child_Dir_1 (which are GrandChild_Dir_1 and GrandChild_Dir_2) to be updated.
I have tried to go to set the "ignore" property of the of Child_Dir_1 to exclude *.LAUNCH files, but each time I update the source code, the ones that I manually deleted are restored to Child_Dir_1.
Since you are using TortoiseSVN:
Go into Child_Dir_1, select GrandChild_Dir_1 and GrandChild_Dir_2 and right click, TortoiseSVN -> Update.
That will update only those two folders.
Ignore is so that you can "ignore" ( from commit, status etc.) untracked files, files that are not checked in.
It could be that manojlds' answer is the solution for you, but I have doubts. The problem here is that those files are really part of the project. They are kind of unavoidable, and must be in sync with the rest of working copy.
Option 1 (best): Remove all configuration files form repository, or better yet have in repository only configuration template files (with, say, $ as first character in file names). Each user could copy those template files to true configuration files and change them accordingly. Configuration files should not ever be committed. Only template files should, but updating template files will not mess with current configuration files of any user.
Option 2 (second best): Ignore those configuration files. Use your own files for your own configuration, with names that don't clash with existing. You may even add your files to SVN, but you may just as well not add them. Does not matter, as long as you don't need your configuration on another machine.
Option 3: Use ignore-on-commit group. Use those configuration files that already exist. Change them to your likings, but don't ever commit them. To ensure that you don't commit them by accident flag them as non-committable (go to commit window, select all non-committable files, right click > Move to changelist > ignore-on-commit). The problem with this is your files are not protected from other users' updates, but may actually be a good thing.
Option 4: Chop the folder out (a horrible hack). Remove Child_Dir_1 from working copy (Right click on it > Update to revision > set Working depth to Exclude). Save the folder elsewhere first, because it will disappear. After that create it again, inside it checkout all subfolders (GrandChild_Dir_1 and GrandChild_Dir_2), and copy your configuration files. Now you have complete control over folder's contents, but update and commit become more complicated.
Edit: There is option 5 in theory, but I doubt it can be implemented successfully. You can try: Use NTFS hard links. Copy the whole tree with all files as hard links to existing files, except .svn folders and their contents. Original directory is used for SVN operations update, commit, add and delete, and new directory is used for editing files. From new directory delete all the files you don't need, and insert all the files you do need that are not the part of SVN. The problem here is minor extra work when deleting files from and adding them to SVN.
Related
I was renaming several files/folders when VS decided that would be the perfect time to crash. On re-opening, I now have 2 versions of the folders I renamed, one with the old name and one with the new. The new folders were not linked to source control, so I added each of them. Now, when trying to delete the old ones, I get the following error:
This operation cannot be completed. You are attempting to remove or delete a source-controlled item where the item is exclusively locked elsewhere or otherwise unable to be deleted from source control.
I know no one else had those files checked out, and all the files in them have the little green + as if they are new files. I can delete all those files so the folder is empty, but I still cannot delete it. I'm also unable to exclude the folder from project.
If I open a file explorer, I can delete the old folder and then VS will allow me to delete the folder. However, when trying to rename one of the folders back, it gives the error above, even though the folder had been deleted.
My internet searching powers are coming up short and I'm not sure what else to try. Any ideas on how I can fix this?
In case it matters, the affected folders contain .cs, .cshtml, and .js files. The OS is Windows 10.
Generally the files/folders are not really deleted from TFS as they are in source control, unless you permanently destroy them, See Destroy Command.
Files and folders under version control can be easily moved, renamed, and deleted from Source Control Explorer. (Make sure you have these folders mapped in your workspace.)
Just check and try below things:
Note that you cannot delete a folder that has pending changes on any
of its children (including if any of those children are being moved
out of the folder – they’re still children until that changeset is
checked in.)
So, in this case you need to move the children out of the folder
and check those changes in, then delete the folder as a separate
changeset.
Besides in earlier version of TFS and VS have some problems with
deleting empty folders. In this case you can try creating an item
inside the folder you are trying to delete. After that try
deleting again. See this article for details.
You can also try to delete the renamed folder from the command line.
Se Delete Command (Team Foundation Version Control) for details.
Get latest first, then try deleting again.
Remap the workspace or create a new workspace and map to a new
location, then try deleting again.
I'm using TortoiseSVN on Windows 10 for my SVN repository. I have now changed some files and folders.
How can I set them to ignore, so that the files/folders are not removed (or changed) from the repository, but just no commit of them takes place?
All appraoches I have seen so far remove the files from the repository.
In TortoiseSVN Settings on the General page (the first page that opens up), there's a Global ignore pattern option that allows you it ignore certain folders or extensions:
If you want to ignore a specific file (or folder), right click the file, click TortoiseSVN, and click Add to Ignore List. You'll get options to ignore the file, any file with the file's extension, and a few others. This property is committed to the repo for the folder.
Note: This option is only available if the file has not already been added to the repo.
If the file has already been added to the repo, there's no option to ignore changes. See Ignore files which are already versioned
You may also want to check out Subversion: ignore modifications to a file locally on one client only. If this solves your problem, you may want to delete this question as a duplicate.
Is it possible to see all descendant files in the marked folder in the Source Control Explorer window in Visual Studio?
Other source control software I have used have this option, and it makes it very easy to iterate through all the files in a folder recursively and see what has changed.
I think TFS does not support this feature, but there are others options available :
Pending Changes
You don't need to iterate through all the files to see what has changed. You can view easily what has changed using Pending changes. A pending change is a change (Add, Edit, Delete ...) that has not been check-in in TFS. You can view these changes for a single directory or the whole Project. In addition, you can check-in pending changes only for one directory. You will always see the summary window to view all changes before. Right-click the item (Folder or File), and you will see options : Check in, Undo or Shelve. More info here.
File & Folder Comparison
In Source Control Explorer, you can compare the differences between two server folders, two local folders, or a server folder and a local folder. Simply right click on the target folder. It's quite a powerfull feature when you know it.
Read morehere.
I am trying to commit a file that is out of date. I tried cleaning the directory and nothing is working... the most recent file on my local machine is the one i know i want to use.. what is the standard way of overriding the conflict... should i just delete and re-add or is there another way "resource is out of date try updating"
UPDATE BASED ON ADVICE TO UPDATE*** I am getting a "checksum mismatch" error
You need to update your local copy of the file. Right click and click update.
Any changes that have been made since your last update will be merged with your current copy. You can then right click on the file and select resolve conflicts.
If you want to ignore any changes that were made and just use your local copy, the easiest way is to copy your file to another location, update, then overwrite the file with your local copy. However you usually will want to let Tortoise handle merging any changes for you.
Did you try an update? You need to update your local copy to the current version in the repository. Right click, and select 'update'.
I had the exact same issue, it turns out that there are hidden folders containing data that tortoise uses to maintain some record of changes that have been made. If the data in your local folder does not match the data in the server, then you get a whole lot of errors that make very little sense.
To fix this, Right click on your folder and click "SVN Update".
IF you still get an error, open your local folder in explorer, enable viewing of system files and hidden files, and look to see if there is more than 1 hidden .svn folder inside your local directory.
In my case, I had accidentally copied another .svn folder into my local directory. This extra .svn folder was causing the update errors. There should only be 1 .svn folder in your root directory.
Delete the extra .svn folder (usually only the local root folder has the .svn folder) and try updating again.
Tortoise should update your local copy and then you can commit your changes without a problem.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)