I currently have a project which I want to add to SVN but I don't want to version certain file types. (e.g. .png) or a folder (images).
I know there's the svn:ignore, but this will not work if there's no .svn file in the directory which I'm trying to perform the ignore operation. I get the following errors :
property 'svn:ignore' set on '.'
svn: 'common' is not under version control
I'm looking for someone to inform me as to how to do this or direct me in the right place.
Any time I'm trying this, its like I have to add the file/directory to svn using 'svn add' and then run the ignore. I've a lot of directories and I'm looking to do this recursively also.
Is there a simple way to do this?
Set global-ignores in Subversion configuration file (normally found on Linux at ~/.subversion/config). See the manual for more info.
Related
I'm using the following method to populate a tags file in my repositories' .git directories:
https://tbaggery.com/2011/08/08/effortless-ctags-with-git.html
So, for any given git repo, I will have a .git/tags file in it. How do I configure my tags option to recursively look up from my current directories in a repo to find these tags files?
I currently have this:
set tags^=./.git/tags,*/.git/tags;~
As I understand it, that should look for ./.git/tags and if it exists use that. Else, it will go up one directory and look for .git/tags there. Failing that, it will go up two directories, and so on, stopping once it hits my home directory (~).
That seemed to work until I had another git repository in the mix. What I find is that if I have two repos at $HOME like so:
~/my_repo_2910
~/my_repo
If I am in ~/my_repo, things work fine. That is, tag resolutions happen via ~/my_repo/.git/tags. However, if I'm in a subdirectory of ~/my_repo, say ~/my_repo/dir, then running my tag commands will resolve to files in ~/my_repo_2910. I'm not sure how that is possible, but it is very dangerous for me to unexpectedly jump repos via my :tag lookups.
Clearly I'm not setting the tags option correctly. Can someone point out what I'm doing wrong.
Update
Knoble's answer works for me if I update my CentOS 7 vim to version 8 following the instructions here:
https://vi.stackexchange.com/a/21697/25433
Then his tags specification works for me fine.
With the recent fugitive updates, I had to fix my tags setup (fugitive no longer sets tags).
I have this line now:
set tags^=.git/tags;~
Note the lack of * wildcard
As sussed out in comments, there appears to be a difference between my version (8+ on macOS) and the OP version (7.4 RHEL)
I would like to present in my GUI the SVN version of a certain file added to the project without hard-coding it each time I change something in the file and re-upload it to the SVN.
Is there a way to do that?
You need to use Subversion keywords, expressed as subversion properties on the file using the svn:keywords property. You'd set svn:keywords to Revision or Id to solve your problem. (Note that this solution updates data in the file, which is exposed when viewing or editing the file. It may or may not be shown an any particular GUI which is not a file editor.)
For more information on svn:keywords check out Special Keywords
For TortoiseSVN, right-button the file, pick TortoiseSVN, Properties, new, Keywords, and check the ones you want applied to the file.
Then, in the file, insert (in comments) the special strings $Revision$, $Id$, $Author$, etc. and Subversion will convert those into the actual data when the file is committed. Then, upon checkout, the data will appear and will be updated on the next commit.
If
your GUI can communicate with repository (i.e data is Working Copy or
you know filename-URL relation)
and
Production system has SVN-client
you can for any file-type get file-revision dynamically
svn ls -v URL (first column) or svn info URL ("Last Changed Rev" string)
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)
Lets say, I know there is going to be a conflict with me committing but I don't want to deal with merging or anything.
I simply want to overwrite the repositories version with my own. What is the tortoisesvn command to do so?
First you have to make an update (SVN Update), so the conflict is actually happening.
Then you get three files in your directory: yourfilename.mine yourfilename.rX yourfilename.rY (X and Y are the original and the new revision numbers)
Rename the .mine file to the original file name.
Mark the conflicted file as resolved. (TortoiseSVN -> Resolved) (The .r? files will be deleted automatically)
After that you can commit the file as it were a normal change. (SVN Commit)
Look at the svn resolve command from the red book. With a command line client, you would be able to run
svn update
svn resolve -R --accept mine-full
It doesn't appear that TortoiseSVN makes this available, but if you have the command line client as backup, it may be handy. Otherwise, I'd go with a hack of the sort Neil describes (move working copy files, update, replace working copy files).
A big caution: Using the Resolved... command instead will accept the conflict-containing version after the update; you really want the file before the update.
Another (horrible) possibility:
Check out the version you know you are going to conflict with into a separate directory from your own stuff
Copy your working files over the ones in the separate directory - take care not to copy the .svn files
Commit from the separate directory
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.