we are working on a project, where the angularjs web project is compiled and binaries are stored in hg repo. The problem is angularjs js files are usually compiled with hashing for all binary files. Ex: binary files are suffixed with unique extensions for each file
main.1cc794c25c00388d81bb.js,
polyfills.eda7b2736c9951cdce19.js,
runtime.a2aefc53e5f0bce023ee.js,
common.7d1522841bf85b01f2e6.js,
1.620807da7415abaeeb47.js,
2.93e8bd3b179a0199a6a3.....etc.
The problem is every time a new binary in checkin in hg repo, it is being detected as new file and retained along with old file of same name. So, i need a way to fool the hg repo, to retain the file name but still consider them as old file replacing the previous one.
main.1cc794c25c00388d81bb.js ==> overwrite old main.js
polyfills.eda7b2736c9951cdce19.js ==> overwrite old polyfill.js
runtime.a2aefc53e5f0bce023ee.js ==> overwrite old polyfill.js
common.7d1522841bf85b01f2e6.js ==> overwrite old commom.js
1.620807da7415abaeeb47.js ==> overwrite old 1.js
2.93e8bd3b179a0199a6a3 ==> overwrite old 2.js
Could any one point out a way, to fool the hg to consider these files are just modification of previous files and not as new files ?
Can hgignore or some other extension be used...
A VCS shall track the state of files. And those are indeed new files. One can argue that those are the old files renamed - which can be recorded by the VCS.
So there are two solutions I see:
Record moving the old filenames to the new filenames. hg addremove --similarity XX might be of big help here. It will result in all the files having the new names each time - but if the similarity is good enough it will work nicely. You might need to adjust the XX to get a similarity measure (0 ... 100) which works for you best. Adding --dry-run for testing purposes might make testing easy. You WILL need to delete the old files before you run hg addremove though.
Have a pre-commit hook which iterates over *.js files and moves via an appropriate regex ..js to *.js omitting the hashing code, effectively overwriting the generic filenames with the newly generated hashed filenames.
Related
I want to write a script that recursively descends a directory tree, and does an hg pull -u on all repositories that are "clean" - i.e. have no local diffs, outgoing changesets, or anything else that might make them different to remote. (The script would also do a rebuild, etc.)
Is there a good way to check whether a repository is "clean"? Keep in mind that I would probably be doing this from a bash or python script.
hg status is your friend. However, you should be careful about what "clean" means. If all files in your directory structure are under version control, and none of them have changed, hg status should return no console output, and (probably) a 0 return code.
If that does not match your definition of clean, you have to be more careful. For example, I commonly do not add generated files (binaries, PDFs from Latex, etc) to version control, but they are inside my directory structure. In that case these files are listed as 'unknown', and I'm sure the return code of hg will differ.
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.
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.
ok, when I was young, I put severial big files(like resource file, dll, etc..) in my mercurial repos. and I found the size of it is so big that I cannot easily push it into bitbucket,
any way to delete this files history EASILY?
I put all those files in /res and /dll path.
edit:
this is a solution, but it will delete part of the history, so maybe there is a better solution.
Mercurial Remove History
Your best bet is to use the convert extension, but warning you'll end up with a totally different repo. Every hash will be different and every person who cloned will need to delete their clone and re-clone.
That said, here's what you do:
Create a filemap file named filemap.txt containing:
exclude res
exclude dll
and then run this command:
hg convert --filemap filemap.txt your-source-repository your-destination-repository
For example:
hg convert --filemap filemap.txt /home/you/repos/bloatedrepo /home/you/repos/slenderrepo
That gets you a whole new repo that has all of your history except the history of any files in /res and /dll, but again it will be a new, unrelated repo as far as mercurial (and bitbucket) are concerned.
I understand how to remove an entire changeset from history but it's not clear how to remove a subset instead.
For example, how do I remove all DLL files from an existing changeset while leaving the source-code alone?
Because the revision ids (e.g. a8d7641f...) are based on a hash of the changeset, it's not really possible to remove a subset of a changeset from history.
However, it is possible to create a new repo with a parallel history, except for a certain set of files, by using the Convert extension. You'll be converting a Mercurial repo to a Mercurial repo, using the filemap to exclude the files you don't want by adding excludes. This will create a new, unrelated repository, which means that any clones people have won't be able to pull from it any more, and will have to re-clone from this new repo.
Make sure all your teammates have pushed their local changes to the
central repo (if any)
Backup your repository
Create a "map.txt" file with the following content:
# this filemap is used to exclude specific files
exclude "subdir/filename1.ext"
exclude "subdir/filename2.ext"
exclude "subdir2"
Run this command:
hg convert --filemap map.txt c:/oldrepo c:/newrepo
NOTE: You have to use "forward-slash" in paths, even on windows.
Wait and be patient
Now you have a new repo at c:\newrepo but without the files
PS. In the "upper" repo you have to remove all changesets and re-push your new repo.
PPS. I actually wrote a blog post about this that has more details (including stripping the changesest in Bitbucket etc.