I'm wondering where to put .hgignore file; in the main repository or each programmer should have it on his cloned copy?
Please clarify. Thanks.
You should put the file at the root of your repository.
See :
https://www.selenic.com/mercurial/hgignore.5.html
https://www.mercurial-scm.org/wiki/.hgignore
It says:
These files can be ignored by listing them in a .hgignore file in the root of the working directory. The .hgignore file must be created manually. It is typically put under version control, so that the settings will propagate to other repositories with push and pull.
Also another advantage is that, you might be working on multiple projects. Each having it's own set of pattern of files to ignore. For example, working on a Visual Studio project or a simple C++ project or a Python project. This ensures that patterns to ignore are relevant to the project.
How ever, you may not want to replicate these patterns in every ignore files. In such a case Mercurial configuration file can reference a set of per-user or global ignore files.
Example for global ignore files
in ~/.hgrc1:
[ui]
ignore = ~/.hgignore
in ~/.hgignore:
syntax: glob
*.tex
*.R
1 On Windows: %USERPROFILE%\mercurial.ini, ~ refers to %USERPROFILE% on Windows.
I've never seen it anywhere but the main repository.
How are you going to ignore the .hgignore without an .hgignore file in the repositry to ignore it ;P
Seriously.. it should probably be in the repository, since the files to be ignored are respositry-specific; a user can of course specify their own ignores additionally in a file specified in their .hgrc
you can have a global one inside your ~/.hgrc directory or a project specific one inside
the project's root directory
It belongs in the top folder of the repository. It is not meant for personal ignores but for project-wide ignores (i.e. applying for everyone). However, usually developers will add e.g. their faviourite editor's temp. files to that file - doesn't hurt anyone.
If you want to ignore something others probably do NOT want to ignore, put it in your personal ignore in ~/.hgrc.
Related
my problem is quite simple: there is a folder in my project which I want versioned, but not pushed along with the rest of the project when I push updates. The situation is that I made an Android app stub along with the project, and I don't want to push it until it is actually somewhat functioning. It's a pretty bulky folder.
I do not want to make a separate branch for that folder, because of two problems: firstly, updating that branch whenever I pull from remote will require a merge; secondly, swapping between the two branches requires noticeable waiting time as the thousands of Android files are created/deleted, and this is very annoying to me.
I was thinking about editing .hgignore in some way, but I think it is wrong that the remote repo will then have my local folder as ignored.
Any suggestions?
You can add this snippet to your repo's hgrc file:
[ui]
ignore = /path/to/.hg/hgignore
where the point about this hgignore file is that it is non-versioned and local to you. The contents hgignore can be anything that would also be suitable for the (versioned) .hgignore. e.g:
syntax: glob
/directory/to/ignore
The name of the file, hgignore, can be called anything, but it's what I use.
You can 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. You can even specify which files you do not want to commit in your directory, e.g., stub/**.c for all C files in the hierarchy of directories below stub.
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).
If this is a temporary situation, it would solve your problem though: you would just have to remove the --exclude parts when you feel ready to commit and push your stub.
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.
Is it possible in mercurial to ignore changes within an entire directory.
For example I would like mercurial to not tell me that changes to the "class" directory have occurred since I don't want to version control the *.class files for my project.
You'll want to set up a rule in your .hgignore file.
There's a pretty good explanation here.
I could have sworn there was a way to keep a local ignore file in an hg repo, i.e. a file similar in function to .hgignore, but not checked into the repo. This could be used to ignore changes to an IDE project file if different IDEs are being used, for example. I'm having trouble finding how it's done. Does anyone recall the details?
This is what I was looking for.
Add the following to the repo's .hg/hgrc:
[ui]
ignore = /path/to/repo/.hg/hgignore
and create a new file .hg/hgignore beside it. This new file will be
untracked, but work the same as the versioned .hgignore file for this
specific working copy. (The /path/to/repo bit is unfortunate but
necessary to make it work when invoking 'hg' from within a subdir of
the repo.)
In version 3.5, setting the ignore property under the ui section changes the global ignore file. To add additional files to be ignored, follow the advice of Jeroen Dierckx and set the ignore.local property to get the same effect as adding to .git/info/exclude in a git repository.
[ui]
ignore = .hgignore
ignore.local = .hg/hgignore
Just make an .hgignore file and add .hgignore to the .hgignore file itself.
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.