I have a configuration file in my project which needs to be in the repository (so new developers get it when they checkout the project). Each developer might change some values in the file locally - these changes should not be committed and I don't want them showing in the synchronization menu (I'm using eclipse and subversive if it matters).
Note that I can't just set the svn:ignore property since it only works on files that aren't under version control - but I do want to keep a base version of the file in the repository. How can I avoid the file showing in synchronization without deleting it from repository?
EDIT: A better description - what I actually need is to be able to set a "read-only" property on the config file, so it can't be changed in the repository as long as the property is on. Do you know anything like this?
Thanks
I do this by having a base version of the file checked-in as foo.base, and svn lock this so that it's read-only on checkout. Then have each developer copy this file to their own personal foo file, which is ignored by svn-ignore.
You can't ignore files which are already under version control. The only way to ignore such files is first delete those files do a commit and after that change the svn:ignore property and do a second commit.
If you like to have a kind of Base-Version use a template which has a different name.
You can version template under different name
OR
Read this answer
once u check out, u can lock it, and once it is locked, others will not be able to commit(make changes to svn) that file. see image below
My solution is that a compile time script creates a copy from the original template file if it does not exist. This copy can be put on the ignore list. I feel that locking a file for this purpose abuses the locking feature (it was not created for this).
Related
In our company, we just started using Mercurial and we are facing the following problem:
We have some files in the remote repository that are changed by each developer to add some local configuration but these files must never be changed in the remote repository.
Is there a way to tell Mercurial to stop tracking those files locally without making any change to the file on the remote repository?
We tried with hg forget <file> but as I understand, this will remove the file from the remote repository.
We also tried adding those files to .hgignore file, but somehow the files are not really being ignored, I guess Mercurial does this because the files are already being tracked.
So far, we are just ignoring the files when we perform a commit and we use shelve to maintain and restore our local changes after an Update, but it's starting to be a really tedious task.
Thanks in advance for any help.
EDIT: Although it didn't completely fix what we wanted to, accepted answer is the best approach. Our problem is probably a result of a bad design.
If the file you want unchanged is, for example, config.cfg, check in a config_template.cfg, forget config.cfg if it is already tracked, and add config.cfg to the ignore list. Then, a build rule can create config.cfg from the template if it does not already exist.
A user will then have a starting config.cfg that they can customize without checking it in.
You could use the configuration [defaults] section to add some "--exclude" options to usual commands (see my answer to Mercurial hg ignore does not work properly ) for more details.
But.. be careful that it is dangerous to silently ignore modifications to files and also that this [defaults] section has been marked as deprecated (it is still present in 2.9.2).
IMHO it's a wrong approach to have a file in the repository which every person needs changed anyway - it's an indication that you do not want to have it tracked at all.
Change the file to config.sample, and have your programme create a default config upon first start (thus when there's no existing config file) and have every developer use the config file as s/he needs.
And I see Mark Tolnen's answer only now :)
I am working with eclipse subversion plugin, and made some local changes to crucial files, which I don't wan't to check in. I'm looking for a way to "lock" (I know that the lock term means something else in svn...) these local files and disable checking them in, so that I won't accidentally check them in.
Maybe you can just ignore them:
Team --> add to svn:ignore
if necessary you can do this via the svn command line. This way you might add a pattern to svn ignore
svn pe svn:ignore .
then you can fill in something like:
*.d
NOTE that svn:ignore is different for each subfolder (hence the "." in the svn command)
The answer largely depends on if the file is already being tracked (versioned) by Subversion or not.
Not Versioned
Setting up an ignore via one of the several methods we have of ignoring files will do what you want. If you're using 1.8 we also have svn:global-ignores which supports inheritance (so if you want to say ignore all files with the .o extension you could just set a svn:global-ignores with *.o as a pattern.)
Versioned
If the file is already in the repository and is versioned then ignore won't help you since versioned files are not ignored by any configuration you do. One alternative, as mentioned in the answer to this question "How do I avoid checking in local changes to the SVN repository?", is to use a changelist and add the file to the changelist.
A better option might be to restructure your setup to not require making local changes to versioned files. A common pattern you will see is configuration files where the committed file is a template, developers then copy the template into another name that is used and customize it.
I am using Eclipse and Subversion for Java development, and I find myself wishing for a feature in version control systems (one that is not available in SVN, to the best of my knowledge).
I would like my project settings files to be half-ignored. To be more precise, I want them to be available in VCS, I want merge to occur when someone checks in changes, but. I want my own changes ignored unless I very explicitly tell the system to take them.
This would allow me to have my local paths (and other settings) in my local configuration w/o screwing up other people's configuration. But, when I have a substantial change, I can still check it in (very very carefully, may be temporarily removing my other local changes) and have it delivered to other people.
Now, the actual question: is there any VCS that supports this feature? Or may be I am missing something in SVN? How do other people solve this problem in Eclipse?
Yes, Git support that feature through filter driver (a clean script can run upon commit, allowing you to clean the content from any of your changes if you want).
But another way would be to never version that setting file, and only version:
a template file
a value file
a script able to replace variables in the template files with the values from the value file, in order to generate the actual (and "private", as in "not versioned") setting file.
That way, you can modifying it at your heart's content without ever committing your changes.
.gitignore for git, .hgignore for mercurial and file paths and patterns can be added that will not be committed. There similar in SVN but i never worked out how to use it myself but my sysop did set it up form me.
git supports this with
git update-index --assume-unchanged <file>
and the complementary
git update-index --no-assume-unchanged <file>
See http://blog.pagebakers.nl/2009/01/29/git-ignoring-changes-in-tracked-files and http://kernel.org/pub/software/scm/git/docs/git-update-index.html#_options for more details.
I have a file with database settings in my project which I have set to some defaults. The file is tracked by Mercurial and checked in. Since this file will be edited with different values various developer machines, is there a way I can tell Mercurial to ignore new changes to this file?
I tried adding the file to the .hgignore file, but since the file is tracked it isn't ignored. This is alright and good in other situations, but I am wondering if there is something I can do here?
Using a file template is definitely the best solution.
For example, if you have a database.ini file, commit a database.ini.template file and ignore database.ini in .hgignore
If you always want to ignore the file, you can add the -X option as a default for commit to your .hg/hgrc configuration file:
[defaults]
commit = -X program.conf
We wrote an extension for this called exclude. It will automatically add the -X options on the commands that support them -- so hg status and hg commit wont see the modified file. It works by reading a .hgexclude file from the root of your repository, just like the .hgignore file. You add the files that you want to exclude there:
syntax: glob
db.conf
The extension works quite well, but there is a known situation where it fails: merges and the commit that follows a merge (this is documented on the wiki). It would need to be improved so that it would save the modifications away to a temporary file and then restore them afterwards. Please get in contact if you need this feature.
There is no truly automated process, but you can try (as in this SO question) the -X option on hg commit:
% hg stat
M myfile
% hg commit -X 'myfile'
(other solutions might involve shelve or hq)
However, this is not the "right" solution. I would rather recommend versioning:
a file template
a script able to generate the final file (that you modify but can ignore altogether)
If you are using TortoiseHG, open the Settings for the repo, go to the Commit section (2nd icon down on the left) & add the file name(s) to the Auto Exclude list on the right (~ 3rd from the bottom in the list).
From https://tortoisehg.readthedocs.io/en/latest/settings.html#commit
Typically you would check in a reference copy of the file and track it then have the developers make a copy of that for local development, you wouldn't really want developers editing the source controlled file for their own environments.
If your configuration system supports it, it's even easier if you can use an override file that simply override values in the reference copy (e.g. the database connection string). That way devs only have to keep a very minimal local set of override values.
If the file is already being tracked, you can issue the Forget command to the file. If you're using TortoiseHg just right click the file during commit and select Forget. The file must also be already in the ignore list.
I had the same problem as yours, I file keeps on appearing on every commit even-though its already in the ignore list. I tried the Forget command and it did the trick.
You can try hg forget.
For more details, see the official manual about the same command.
It worked for me.
I think, something like this is closer to a correct answer to the original question Mercurial: How to ignore changes to a tracked file, rather than the others suggesting a template, etc.
I thought I'd get myself a Subversion setup at home for my hobby projects, and I'm trying to do it right, first time (my work's source control control policies or lack of them are, well, not perfect).
The thing I'm struggling with is this: I'd like to version entire Eclipse projects. This will be good from Eclipse's point of view - I'll just let it do its thing, and should just mean I need to ignore a few binaries / whole build directories and set up these ignores just once when I set up the project (right?). Anyway, I've tried it a couple of times and svn seems to get confused and ignore my ignore settings. What should be the correct procedure?
Thanks.
PS I'm doing the svn bits from command line, trying to avoid a GUI till I'm happy with it.
There are basically two ways to instruct subversion to ignore files either by name or by pattern.
The first way is to find the configuration file (location depends on platform) and add the file name or pattern to the global-ignores list. This applies to all svn operations on the machine or for that user.
The second way is to set the svn:ignore property on a versioned directory, for example:
svn propedit svn:ignore myDirectory
This brings up an editor for the svn:ignore property where you can add for example:
bin
obj
*.bak
Note that this property change is also versioned and needs to be committed, after that they apply for everyone working on that directory (after an update of course). This property doesn't apply recursively to subdirectories.
For more info see the svn book.
IIRC, Subversion won't stop you from svn adding files that you marked as ignored if you explicitly add them by name (though it may warn you). The svn:ignore property is primarily there to prevent them from showing up in svn status.
Also, AFAIK, the svn:ignore property is not recursive, so it will only work on first-level children of the directory it is set on.
If you on a linux box, you can try these steps, if on windows, pretty the installer shall do things for you.
https://help.ubuntu.com/community/Subversion
Also the subversion book might help
http://svnbook.red-bean.com/en/1.5/index.html
Could you be a bit more clear about what specifically svn is getting confused about? Remember that the svn:ignore property is a per-directory setting; i.e. if you want to ignore .foo files in ./bar and in ./bar/abc, you need to edit the property for each directory. Yes, it is a pain in the butt.
There are a couple of ways I've added projects to source control. Here's a higher level description:
One way is to import an empty top-level folder, then svn checkout, then copy the project files to that working copy, then svn add all but the files to be ignored (or svn revert specific files/folders) and set ignore properties as desired, then commit.
Another way is to make a copy of the project files, manually delete files and folders to be ignored, then svn import. Then delete those files. Then do an svn checkout, then setup the ignore properties on that working copy and svn commit. Then copy the original ignored files/folders to the working copy.
Of course, the more things that are globally ignored the easier these steps will be.