In Mercurial (preferably via TortoiseHG interface) is it possible to copy a committed file, and for the new destination file to share the history for the source file?
I'm pretty sure this is not possible, but I'm asking in the hope that it's just really well hidden in the documentation.
I have a file with a fairly long history of changes, but I now need to have have a 2nd copy of this file within the project which will contain it's own individual changes. However, it would be exceedingly useful to be able to view the history of this copied file and see all the changes that took place on the original before the copy took place (as well as those that have taken place since the copy).
Update
Thanks to #Inspired for their answer. As I said in my comment to them, I was at fault...
I just realised why it wasn't working: I didn't copy the file through either the command line or THG, but through Visual Studio (2010) using VisualHG. VHG must copy the file and then add it, rather than using the mercurial copy function. So I need to remember to use mercurial directly in the future!
Or to be more precise, my guess is that VisualHG cannot override the default functionality of Visual Studio, and therefore can only work with the copied file, rather than run the mercurial copy command. This is purely my guess.
From command line, you can issue hg copy <old name> <new name>. Mercurial does save the history log when you perform copy or rename (hg cp / hg mv).
In TortoiseHG the copy is a bit tricky: you have to copy the file manually (e.g. via cp), then in THG in Commit mode right-click at the left low pane with the unversioned new file and select Detect renames. Uncheck Only consider deleted files, let TortoiseHG find similar files and click the source file when it finishes. TortoiseHG will record the new file as a copy.
I haven't found a simpler way.
When viewing history from command line, you need to specify -f (or --follow) when you are viewing the history: hg log -f <filename>. TortoiseHG already does that.
Related
I have a file (some kind of database) which is updated as developers test their code and pushed to a central mercurial repository.
I would like everyone to reuse this file and therefore whenever there is a pull / update from our central repository the local version should be replaced by the one stored centrally. In other words I would like to do a hg update -C for that file only, and having it done automatically upon a pull.
Is this possible to do with mercurial?
Developers can add a hook that does this, but you can't make them (unless you have control over their machines).
Something like this in a clone's .hg/hgrc file will delete the local file so the update replaces it fresh:
[hooks]
preupdate = rm path/to/databasefile
Keep in mind, of course, that update will put in place the version of the file as it appeared in the changeset to which the user is updating. So if you do hg update --rev 0 you'll get the very first version of that file, not the one in the most recent revision.
As an aside, usually if there's a file that changes a lot and is unumergeable you're better off having it be an untracked/ignored file that's fetched out of band -- for example, have your launch script download the latest version.
I have a file default.config in the root of my repository. I tweaked it for my own setup, and I do not want to commit it. Ever. What are my options other than commit -X "^default\.config$"?
I added ^default\.config$ to .hgignore, but it still shows up in the output of hg status -mard.
Edit: maybe it's possible to do this with Mercurial Queues. If I keep all my local config changes in a single patch, then I just have to remember to pop it before committing. Just thinking out loud...
Follow these steps:
Copy the file somewhere outside your working directory
Remove the file with hg rm default.config and commit the changes
Copy back your file to the working directory
As a good practice you can add a file called default.config.template or something which is committed to the repository. This file holds some kind of default values or comments on how to use it and other users/developers can copy this file to default.config if they're using your project.
Akluth has the correct answer: commit a template file to your repository and then copy that to the real name in each working copy. If the config file supports it, then use an include directive to load the template file from the real config file. Something like
// default.config
//
// load defaults from versioned template file
#include "default.config.template"
// override defaults with my settings
db_hostname = localhost
db_user = me
An alternative is to use -X with every command, as you suggest. There is an exclude extension that implements this idea. Remember to read the caveats — it doesn't work when merging because you cannot exclude files when committing a merge. The extension would need to be extended to handle that case, probably by shelving change before the merge and unshelving it afterwards.
This suggests another stragety, similar to using MQ as you suggest: use the new shelve extension in a set of pre- and post- hooks to shelve/unshelve the file before/after each operation. I think that could work, though I haven't tried it in real life.
When trying to export a patch for a commit, the resulting patch file doesn't include empty files that were added in the commit.
Steps to reproduce:
Create a new folder and initialize it as an Hg repository.
Add some zero-byte file to that folder, and create an initial commit for that file.
Create a second zero-byte file, and create a second commit for that file.
In Hg Workbench, right-click on either of those commits, and choose Export >> Export Patch.
Open the resultant patch file in Notepad / any text viewer.
Observe that the patch file does not contain any information about the new files that were added.
It seems like the newly added files should be included. If I exported that patch and someone else applied it, they wouldn't really be getting the full changeset, since the new files aren't included.
Can someone tell me what I'm doing wrong, or why it behaves this way? This is not the behavior I expected.
I'm using TortoiseHg 2.7.1, which includes Mercurial 2.5.2.
I don't want this file to be removed from other developer's machines, but I don't want it tracked anymore either. It is basically a setting file, that shouldn't have been checked in in the first place.
I think I have to tell the other developers to back up this file. Then I can do a remove, and add it to the .hgignore. Then they have to put the file back into their working directory.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Any tips?
They don't need to back it up. It's backed up in the repository. You might want to get them to commit their latest version before they pull from you so they don't lose their latest changes. When they lose their file they can just do hg log <file> and then hg revert <latest revision - 1> <file> to get it back.
It seems like hg forget would only work for my machine, and then next time another developer does a pull it would wipe out their file.
Yes, non-versioned file will be saved (some time) only in your WC
If you don't want kill file and just ignore, you can
use -X filename on commit by hand (or write in aliases section)
install (on all workplaces) Exclude Extension (semi-automated solution from p.1)
So I have a directory called flash. I'd like to move it totally from an existing Mercurial repo located at ~/wdm to another existing Mercurial repo, located at ~/wdm-js.
I've been told this is possible with hg convert, but I don't really know how this works. I have tried the following, but think I may have got something wrong.
Having read up on the hg convert for Mercurial docs, I've created a filemap, which reads as follows:
include flash
Then I've gone to ~/wdm and run the following command:
$ hg convert . ~/wdm-js --filemap ~/filemap.txt
I've seen a load of output as follows:
scanning source...
sorting...
converting...
413 [doc/design][m]: first stab at a design doc for model (sent to list).
[412 more history items]
So this looks fairly promising. But when I look at wdm-js there is no flash directory there. And none of the flash directory files have moved from the wdm directory. And the hg status of both repos looks no different.
Do I still have to copy the flash directory across manually, and hg add/hg remove all the files manually to both repos?
Or... should this have been done for me, meaning that I have messed up in some way?
hg convert doesn't update the working directory in the destination repository (it leaves it at the original null revision), so do a hg update there to see the files. Also, the way you ran it, it copies the files; you can either delete them from the original repository via hg forget or hg remove, or use hg convert again using a filemap with the line:
exclude flash
To copy into existing repository you need first copy flash folder into new repository as you did it with convert command and then push the changes from new repository into existing target repository.