I'm not going to get into the discussion on how to set up mercurial for a Drupal multi-site installation, but I've run across something that's boggling my mind.
I have a drupal multi-site installation which I'm trying to set version control up on. What I've done is to hg init in the Drupal Root, with an .hgignore that ignores drupal_root/sites/. This is what Is in my .hgignore, and it seems to be working fine:
# Glob syntax
syntax: glob
# Everything in sites
sites/*
This is working just fine, as mercurial finds everything else besides the sites folder. Now, inside the sites folder, the structure looks like this:
sites/
sites/all
sites/default
sites/domain1.com
sites/domain2.com
My problem is that when I do hg status inside sites, mercurial will not find sites/all/modules. I've tried multiple permutations of .hgignore, as I'd like to ignore sites/domain1.com/files, but nothing seems to work. I even deleted the repo, and started over without any .hgignore at all. sites/all/libraries and sites/all/scripts both show up just fine.
Could the .hgignore in the parent directory have something to do with it?
UPDATE: I just completely removed the sub-repo (I know it's not actually a sub-repo, but I'm limited here) deleted the repo in drupal root, and started over treating the entire installation as a single repo. Same thing, mercurial just will not find root/sites/all/modules.
UPDATE: #Ry4an - The behavior in the drupal root directory is correct. I'm trying to emulate sub-repositories since I'm stuck using Hg 1.3, which doesn't really implement them. So, my directory structure looks like this:
drupal_root/
.hg/
modules/
includes/
themes/
sites/
.hg/
all/
default/
domain1.com/
domain2.com/
So, I do want the repository inside drupal_root to ignore everything under drupal_root/sites, but I have a second repository inside drupal_root/sites that should handle everything there. That's the repo that's not finding everything.
What you're seeing is the behavior I'd expect. This glob rule:
syntax: glob
# Everything in sites
sites/*
ignores everything in sites, which includes 'sites/all', so Mercurial won't be looking down inside 'all' at all, so it won't see 'sites/all/modules'.
If you provide a full list of files and their paths annotated with what files you want ignored and what files you don't want ignored I'm sure someone can help you come up with the right rules, but it's not entirely clear from your question.
If you task is "ignore all, except one dir"
If you can write (and test) regexps
you can consult with this question and accepted answer in order to adopt regexp to your conditions
Another (slightly more inaccurate) solution can be
leave current "ignore all" pattern
add all files in sites/all/modules into repo by hand (hgignore ignore only untracked objects)
don't forget all new files, added later into modules, add explicitly to Mercurial (they will be ignored by rule)
Well, I feel like an idiot. The problem was that there was already a repository inside drupal_root/sites/all/modules. I don't remember putting it there, but it seems that mercurial ignores any directory that already contains a .hg directory. Thanks for the help everyone.
Related
I've been having some problems with mercurial and kiln, maybe you can point me in the right direction. Sometimes when I commit the files they get renamed as Upper Case 'Assembly.NameSpace' will be changed to 'ASSEMBLY.NAMESPACE' and if I try to commit after making changes to them they appear as not being tracked (Side note I found out about the renamed files after I committed).
No matter what I do they just wont be tracked. I tried add using the console, using hg workbench and nothing seems to work. For it to work I need to forget the files, then commit, then add them again and then commit, which it really sucks for me.
Is it possible the files already exist in the repository with different case? "Case Folding" is a problem for any system that needs to work on both systems that are truly case sensitive and those that are only case retentive. Mercurial has done a lot of work to degrade as well as possible when a case folding problem arises and there's a lot of detail about it in the Mercurial wiki.
On what OS are you working?
When you do that initial add of the files are you using a wildcard or specifying them by name?
Do the files on disk actually change case when you add them? Mercurial only alters files in the working director (the stuff outside of .hg) on update, so it seem pretty much impossible that just doing hg add; hg commit would change the case of a file in the working directory.
Upgrading to latest version will fix the problem.
There are one or two files, like .hgignore, which I generally want to be the same in each of a bunch of projects.
However, the nature of these files means that I can't simply move them to a common shared project and just make the other projects depend on that project. They have to be inside each project. Symbolic links are not an option either because some of our developers use Windows.
How can I share these files between repositories and have changes propagated across (on my local machine, at least)? I'm using Eclipse.
For your specific case of hgignore you can put an entry like this in each project's .hg/hgrc file:
[ui]
ignore.common = ~/hgignore-common
If you you know your common library will always the in the parent directory, as is often the case with a subrepo setup you could do:
[ui]
ignore.common = ../hgignore-common
or if you know it will always be in a sibling directory of project checkouts you could do:
[ui]
ignore.common = ../company-wide-defaults/hgignore-common
Unforunately there's no absolute way to reference a file that's valid everywhere, but you can at least to to a point where on your machine all your checkouts are referencing a common ignore.
Hardlinking instead of copying the relevant files sort of works with Eclipse - although you have to refresh each of the other projects to get it to pick up the change. However, you can configure Eclipse to watch the filesystem and automatically refresh whenever it needs to - I recommend this.
It does not work by default with Emacs, because Emacs breaks hard links (which is normally the right thing to do, but is not what you want in this case). However, you can disable this behaviour for multiply-linked files with (setq backup-by-copying-when-linked t).
Starting here,
I'm wrestling with this right now. I've got two folders: Source and SQL. Source has multiple project folders. The project folders in Source and SQL have bin folders. I want to ignore all files in bin folders under Source, but not under SQL. I thought one of these might do the trick:
glob:Source\*\bin\
glob:Source\*\bin
glob:Source\*\bin\*
glob:Source\*\bin*
glob:Source*\bin\
glob:Source\*bin\
But no dice on all of the above.
It seems I'll have to enter a line for each folder under Source where I expect to have a bin folder (and then update my .hgignore file whenever I add a new project).
glob:Source\Project1\bin\
glob:Source\Project2\bin\
#etc
If this is not the case, any advice would be appreciated.
Have you tried a regexp:
syntax: regex
^Source/.*/bin
Also, do remember that anything you've already added isn't affected by ignore rules, so you need the files to be untracked to test this stuff.
Lastly, consider making each project a separate repo -- that's the standard advice in DVCS land be it Mercurial or git. In svn multiple projects in the same repo isn't such a bad idea because you can have different parts of the working directory updated to different revisions, but with a DVCS all files are updated/checkedout to the same revision, which makes putting multiple Projects in the same repo a hassle in general and a really bad idea in some circumstances.
Looking at my .hgignore file, my slashes seem to to be the other way around (a forwrad slash instead of a backslash). i.e:
glob:*/bin/*
Try that maybe?
I'm managing $HOME using Mercurial, to keep my dotfiles nice and tracked, or at least the ones that matter to me.
However, there's a profusion of files and directories in ~ that do not need to be tracked, and that set is ever-changing and ever-growing.
Historically, I've dealt with this by having this .hgignore:
syntax: glob
*
This keeps my status clean, as far as it goes, making only previously tracked files visible. However, I have some directories (in my case, scripts, .emacs.d) that I would like to see untracked files in; I almost always want to track new additions to those directories.
I know that I can run hg st -u scripts to identify untracked files, but I want a means whereby I can achieve the same function using plain ole hg status.
Is there a way to do this?
Try this in .hgignore instead:
syntax: regexp
^(?!(scripts|foo|bar)/)[^/]+/
^ matches start of path
(?!(scripts|foo|bar) uses negative lookahead to ignore all files except those in directories scripts, foo or bar
/) ensures that directories which have a tracked directory as a prefix are ignored
[^/]+/ then actually matches any directory (excluding those ruled out by the lookahead), so that files in ~ aren't ignored
Credit for the central idea in this solution (the negative lookahead) goes to Michael La Voie's answer to this question
This question has been asked here on SO quite a few times, and you'll get a lot of convoluted answers using zero-width negative look ahead assertions, an oft abused regex trick, but the better solutions are to either (a) just make the repo in that directory alone or (b) just add the files in that directory. For option (b) you'd just put .* in your .hgignore file to ignore everything, and then manually hg add the files you want tracked. In mercurial, unlike svn and cvs, you can override an ignore with an add.
Here's what I have in my Mercurial.ini ...
[extdiff]
cmd.bcomp = C:\Program Files\Beyond Compare 3\BCompare.exe
opts.bcomp = /leftreadonly
So, the extdiff extension is working fine except that even when one side of the comparison is my working directory, as in the case where I only give one revision argument, e.g. hg bcomp -r 25 to get a diff between rev25 and the working directory, it causes my diff tool, in this case BC3, to open up a folder comparison session comparing a snapshot of rev25 to a snapshot of the working directory, such as...
left: C:\Windows\Temp\extdiff.v20d13s\MyCode\
right: C:\Windows\Temp\extdiff.q78g269\MyCode\
Is there a way for me to tell it to diff against the actual live working directory on the right side so I can edit from inside the diff tool? This seems to work just fine through SVN's external diff functionality. I realize it will display a lot of orphans on the right --I'll be glad to suffer through having to filter those out.
I've never found a way to prevent extdiff from copying the changed files to the Temp directory, but if your diff tool allows in-place edits then Mercurial will copy the changed files back to the working directory when you exit the tool.
For example, using Beyond Compare, this is the relevant piece from my Mercurial.ini:
[extdiff]
cmd.bcomp = C:\Program Files\Beyond Compare 3\BCompare.exe
opts.bcomp =/expandall /solo /lro
extdiff only copies divergent files between the two changesets to the temp dir, so that the diff tool will not show identical files. It'd be nice if it could detect that one version is working copy and just pass the working directory, and any decent diff tool should allow you to ignore identical files.
That's why if you do hg bcomp <file1> -r<rev> you'll indeed see the working copy because there's only one file to diff.
#Niall C's answer is great, but if you're not comfortable with changing temp files, or your diff tool isn't as cool as bcomp, it shouldn't be hard to write a little extension to copy the files from the non-working copy changeset to a temp dir just like extdiff does, then invoke diff tool between the temp dir and your working dir.
I'm NOT an expert at Mercurial, but I'm having some problems with extdiff as well, and I MAY have inadvertetly found the answer to your question while trying to figure out mine. I may also be completely wrong. ;-)
Anyway, it looks to me like if you explicitly provide a version number to compare against, extdiff takes a snapshot of both versions you're trying to compare (even though you didn't specify BOTH sides of the DIFF; the unspecified side is implicitly the working directory).
The only way I've been able to get extdiff to simply work off of the working directory is to not specify a version to compare to (I guess doing this works off of the tip?).
Sorry I'm not terribly helpful. Hope you find your answer!