Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Tuesday, November 08, 2011

hgignore

hgignore:

'via Blog this'

Most version control tools have a .ignore file or ignore - .cvsignore, .hgignore, vk ignore, bzr ignore, etc.

All that I am aware of ignore fils based on pattern matching on the filename. E.g. in Mercurial:
An untracked file is ignored if its path relative to the repository root directory, or any prefix path of that path, is matched against any pattern in .hgignore.
I would like to extend this to be able to do simple queries.

E.g. I usually have an ignore rule that looks something like
*.novc/
I.e. I ignore directories that are suffixed .novc (for no version control).

This works fine, but is somewhat verbose. Plus, it gets in the way when certan tools have other conventions about names.

I should like to get the .novc directvetive out of the filename, and into a placeholder file in the directory.

E.g. if .../path/.novc exists, then ignore .../path

Q: is it there, and I do not know?


2 comments:

Paul A. Clayton said...

According to http://schacon.github.com/git/user-manual.html#ignoring-files git provides something like this feature: "You can also place .gitignore files in other directories in your working tree, and they will apply to those directories and their subdirectories."

So it is a little more complex than a simple dummy file (where the file name itself indicates ignore all in this directory), but it should be almost as easy to use (and would appear to be more flexible).

I hope this helps.

Andy "Krazy" Glew said...

Doesn't help, but is good to know - I already knew this.

What I may have made explicit is that I try to create a directory tree that is version control agnostic. I have moved stuff regularly between cvs, got, and hg; less regularly between those and svn, bk, bzr, and sccs.

In fact, on several occasions I have created directory trees that were dual VCS: e.g. a tree that was checkec into git, and which also had cvs files or rcs files in it; more recently, a tree that was checked into both git and hg, i.e. that had both .hg and .got directories in the top level. (Sometimes I check the .git files into .hg, sometimes vice versa, sometimes not).

So, I am looking for something pattern based. Where I do not need to adjust it according to whichever VC I am using. Where I can set up a pattern in m,y .gitrc, .hgrc, .cvsrc (or whatever) and have it work as I mess with things on the fly.

By the way, my usage model tends to conflict with the "your checked out tree is just a branch or a repository) philosophy of so many modern tools.

Even more often than full source trees that are multihomed in different version control systems, I may have subdirectories.

E.g. my glew-home is currently version controlled in hg.

But nobody supports nested repositories well, except for CVS and SVN. (Actually, I don't want "nested repos", where I tell you in advance. I want every subdirectory tree to be a repository in its own right, checkoutable and checkinnable without accessing the whole tree.)

So I occasionally use other VCs for subdirectories. E.g. .git for glew-home/src, etc.