Using Tortoise SVN 1.6.16
Steps
In the SVN repo directory, right click and select TortoiseSVN -> Properties.
Select the property svn:ignore and Edit.
Remove the desired file name from the property (in my case it was the only file, so the property is now empty).
Click OK a time or two.
In the SVN repo directory right click and select SVN update.
Expected result: The file gets updated.
Actual result: The file is still "skippped."
Other things I have tried include completely deleting the svn:ignore property, and even restarting this computer.
The canonical way to address a configuration file that everyone has to modify is in the Subversion FAQ.
You should have a template of the configuration file which is versioned, then each developer makes a local copy in which they make their changes (local IPs, etc.) and ignore that file in the WC.
For example, you might have app.config.template which is the template of app.config. app.config.template has placeholders for those per-user/per-workstation settings. The developer, after they check out the project, makes a (local filesytem) copy of app.config.template named app.config (not svn cp. The directory holding the file(s) then has svn:ignore set to ignore app.config.
This worked, but other answers are still welcome:
"Add" the file (but do not commit).
"Revert" the file.
"Update" the file.
In that order.
Related
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.
I'm trying to open an existing Perforce application. I made some local changes, like deleting files, which I want to undo (that is, I want my local copy to exactly match the repository once more -- delete added files, restore deleted files, and undo changes).
When I try to revert using the p4v gui client, I see this error:
file(s) not opened on this client
What am I doing wrong?
I did manage to revert all the changed files, but not the added/removed files.
Edit: I did the following:
Connect to a Perforce server using p4v
Map a directory to my local file system (lets say C:\Perforce)
Get the latest version of the repository
Go to C:\Perforce in Windows Explorer
Delete some files and folders
Add some files and folders
I would like to get back to the "pristine" state, the copy of exactly what's on the server when I got the latest version of the repository for the first time.
By the looks of the edited description you added and deleted files directly on the filesystem and not through perforce. Therefore Perforce doesn't know anything about those changes so there is nothing to revert. Typically when you want to add a file you use 'p4 add" (or the equivalent p4v operation), and when you delete, you should use 'p4 delete' (or again, the equivalent p4v operation).
Really, the best option to get back to a pristine state is to nuke the local copy of the code in c:\perforce (in windows explorer), go to p4v, right click the area you want to sync, and choose "Get Revision..." and in the subsequent dialog, make sure that the "force operation" checkbox is checked. This will tell Perforce that you want a new copy of everything regardless of whether you had it synced or not.
You can also run "reconcile offline work" in p4v. Right click the depot area and choose that option. It will scan through the local folder structure and give you a report of what files have been added that don't exist in perforce, what files were deleted, and what files were modified. From that dialog, you can right click on local files that don't exist in perforce and delete them, or you can 'p4 add' them. You can also sync deleted files.
HTH.
Just an extra not to point out another cause for this.
If the file name contains an unusual character that cannot be translated correctly the name on the client will never match that on the server.
The solution in this case is to spot that character in the file name (it will be a question mark emblem on Linux) and use a wildcard to help identify the file to the server so it can delete it etc (p4 deleting the file is a way to go).
This answer may not be your case. This happened to me when I edited the files on my local disk without logging into p4.
A quick fix at commandline is:
p4 login # make sure you've logged in
p4 edit <filename> # let p4 know you've edited the file
p4 revert <filename> # revert to "pristine" state
You can use p4 reconcile -w to restore your client to the state of the server. There is an alias called clean, which is also available in P4V on the right-click context menu as Clean....
There are several additional flags to control whether added and deleted files are deleted or restored, respectively.
The -w flag forces the workspace files to be updated to match the
depot rather than opening them so that the depot can be updated to
match the workspace. The -a, -d, and -e flags when used with -w
update workspace files as follows:
-a Files with no corresponding depot file are deleted.
-d Depot files not in the workspace are added.
-e Modified files are restored to the last version synced.
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.
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)