How do i recursively remove folders from mercurial tracking system - mercurial

I have a working directory structure like the below one :
mercurial_working_dir:
project1
project2
project3
Under each project folder there are common folders that i want to untrack from mercurial.e.g:
i dont want any file to be tracked under /metadata folder which is common at the 3 projects.
As far as i know i should use hg remove -Af command with the specifing files.Is there any way to define regular exps at the command in order to recursively "remove" the current version of any file under the metadata folder which is placed at all my projects?

Take a look at the chapter about file names and pattern matching in the mercurial book. You can use a pattern like this:
hg rm "glob:**/metadata/**"
If you prefer regular expressions, you can also use the re: prefix instead of glob:.

Related

how to remove a folder from tracking in mercurial

To ignore ./node_modules/ folder and .idea folder into .hgignore file so that I don't want to track them.
Currently I have the following rules on my .hgignore file.
*.orig
*./node_module/
*.idea/
*.rej
*~
*.o
tests/*.err
But abort error on hg status.
Well, hg help hgignore points to have a look at hg help patterns. I can't quite explain it better:
Mercurial accepts several notations for identifying one or more files at a
time.
By default, Mercurial treats filenames as shell-style extended glob
patterns.
Alternate pattern notations must be specified explicitly.
Note:
Patterns specified in ".hgignore" are not rooted. Please see 'hg help
hgignore' for details.
To use a plain path name without any pattern matching, start it with
"path:". These path names must completely match starting at the current
repository root.
To use an extended glob, start a name with "glob:". Globs are rooted at
the current directory; a glob such as "*.c" will only match files in the
current directory ending with ".c".
The supported glob syntax extensions are "**" to match any string across
path separators and "{a,b}" to mean "a or b".
(...)
Plain examples:
path:foo/bar a name bar in a directory named foo in the root
of the repository
path:path:name a file or directory named "path:name"
There are alternate ways to specify paths using regex as well as also explained in the available command line help.
So, use something like
node_module/**
.idea/**
or
path:node_module
path:.idea
provided you quoted your entire .hgignore and thus use the default glob pattern matching.
finally i found tip . here is how to .
Foradding node_modules/ and .idea/ folder you need to specify the following.N.B > is refers terminal.
touch .hgignore
nano .hgignore
add the following
^node_modules/
^.idea/
Done !

Can I use wildcards in the filemap of hg convert

I have a repository with one file (subdir/a.txt), and the one revision, adding it.
If I run hg convert with a filemap consisting of include subdir/a.txt, it works just fine.
But if the filemap is include subdir/*.txt, include */a.txt, or include **/*.txt, the resultant repository has no revisions in it.
Is it possible do use wildcards in the filemap of hg convert?
--
The reason I want to do this is so that I can create a new repository with history, but without any binary files. I want to be able to do something like exclude **/*.dll. Is there any way to do that?
Wildcards do not seem to be supported, but you can use hg manifest --all to get a list of all files present in all changesets, and do some filtering and editing of the output to generate what to exclude. Something like the following to list all the DLL file paths on Windows:
hg manifest --all | findstr \.dll

Create a new repo from sub folder in Mercurial Repo using convert

I am trying to extract a folder (call it Project1) from an existing Mercurial Repo (call in MainRepo) using the Convert extension for Mercurial to Mercurial conversion. I have followed the methods described by Mercurial developers (and elsewhere on the web) under Windows XP:
C:\MainRepo>echo include Project1 > ~myfilemap
C:\MainRepo>echo rename Project1 . >> ~myfilemap
C:\MainRepo>hg convert --filemap ~myfilemap . C:\Project1Repo
C:\MainRepo>cd \Project1Repo
C:\Project1Repo>hg update
This creates the new repo (Project1Repo) with the Mercurial folder/files in place.
But it does not:
1) Carry across the History relating to the changes made for the Project in folder Project1. (Only the very first history entry for MainRepo and a Convert item are present).
2) Copy across all the source code files from the MainRepo\Project1 to Project1Repo.
I have seen the other similar questions and answers in stackoverflow but these do not appear to help (I have followed methods discussed in them):
Can I clone part of a Mercurial repository?
So the question is: How do I extract a sub-folder from MainRepo with only the sub folder history intact and complete to a new Repo and transfer the source files at the same time? (though I guess a straight copy will do the last). It's keeping the history that is important - In this case I can make this after a date or Changeset number.
Any help much appreciated as I'm relatively new to this
Thanks
The workflow you listed is correct. That is the way the convert extension is intended to work.
Your question states that the repo output by hg convert is actually empty (except for "the very first history entry for MainRepo and a Convert item"). This would indicate that convert was not able to find the path specified in your filemap.
Are you certain that the path given your include statement is correct?
The directory name given in your include statement must be the full path from your repository root. For example, your include statement:
include Project1
requires that the path to Project1 actually be:
C:\MainRepo\Project1
If Project1 is actually located somewhere else in MainRepo, you will end up with an empty repo after the conversion.

How do I make mercurial ignore any file with .xxx extension

I want Mercurial to ignore any file with a certain extension.
For example, I wanted to ignore files with a .SUO extension. (There's no need to version-control Visual Studio user settings.)
So I changed my .hgignore file to this:
syntax: glob
*.suo
However, this has no effect, and Mercurial still sees my .suo file.
What am I doing wrong here?
If, when running hg status before altering your .hgignore file, the .suo file had a ? in front of it, then it should be ignored now. If anything else (M or A for example) it is already tracked by the repository and will not magically stop being tracked. In such a case you'll need to do hg remove on the file to delete it and have hg stop tracking it, or just do hg forget on it to have hg stop tracking it but keep the file. Either should be followed by a commit.
The only files that will be omitted from the status listing if their path matches a pattern in the .hgignore file are files that are not tracked. It would make no sense to omit a file that is tracked, because you would never see whether it had been modified, added, or removed.
Edit: Mercurial does only track files (you can't make it track empty directories), but the patterns in .hgignore are simply run against strings of the file paths relative to the root of the repository. The very same relative paths that it shows you when you run hg status. So it does work how you say you want it to work because the following lines are a standard part of my own .hgignore files:
syntax: glob
*\obj\*
*\bin\*
*.csproj.user
*.suo
Again, when you run hg status and it shows a .suo file, what single character is at the beginning of that line? Is it a M, A, R, ! or ? character? What is the path after it?
Mercurial uses entries in a file called .hgignore to determine what files it completely ignores. It is normally located in the root file for your repository (and not in the .hg directory, which you might think).
You can find out more here:
http://www.selenic.com/mercurial/hgignore.5.html
Normally, we use regular expression syntax to ensure that case is not a factor in extensions:
# use regexp syntax.
syntax: regexp
(?i)\.dcu
(?i)\.identcache
(?i)\.dof
(?i)\.dsk
(?i)\.bak
(?i)\.old
That way, it ensures that even if for some reason the case of the extension changes, it is still ignored.
Example for ignoring/excluding files with .o extension:
.*\.o$
should translate to .*\.suo$ for .suo extensions.
I have used this method successfully
Check where .hgignore file is located and ensure it is either in $HOME or project root folder. Check the CASE (vs case) of the extension. I doubt if pattern matching is case insensitive.
edit: tested, the pattern matching is NOT case sensitive. Hence, add "*.SUO" if you want to ignore files with ".SUO" extension.

What's the correct wildcard syntax to copy TeamCity artifacts to the root of a destination path?

I'm having a small drama with the wildcard syntax in my TeamCity artifact configuration. I want to grab every file matching the pattern myproject.*.dll from any folder and place each DLL in the root of the artifacts path.
Here's what I've got at present:
**/obj/Debug/myproject.*.dll => /
This is grabbing all the DLLs but it's putting them inside the same folder structure as the source so rather than ending up with "myproject.web.dll" in the artifacts I get "Web/obj/debug/myproject.web.dll".
What am I missing here?
I'm afraid you cannot do this in an easy way.
You should collect your *.dll locally to a single place, and than use TeamCity's artifacts rule to copy all of them to root directory.
Or, you can enter all paths manually (without ** part)
This is how it works in TC.
I am not sure you can use the artifact root without it copying the structure. The docs specify
If target directory is omitted the
files are published in the root of the
build artifacts.
Can you not just use a designated folder name say dist, would this cause issues? If so what are they!
e.g
**/obj/Debug/myproject.*.dll => dist
Update - found some more info in the docs
The files will be published preserving
the structure of the directories
matched by the wildcard (directories
matched by "static" text will not be
created). That is, TeamCity will
create directories starting from the
first occurrence of the wildcard in
the pattern.
So if you can be more explicit it may lead to a flatter structure.