We have a Mercurial repository on BitBucket. This repository is used by a bunch of people.
Now I have another local repository which is a super-set of the BitBucket repo. What I want to do is work in my repo and get changes from the other repo whenever the others commit and push. I do not want to get the history of those other files just the last revision.
What is the best way to do that?
At the moment, I have cloned the other repository and I pull changes from that one into mine. That works but my issue is that whenever I get a change I have to do a huge merge in order to fix my repository. Is there another way to just get changes from the other repository and put them in my branch? I don't care about getting the history of those files. I could just copy and paste them in my repo but I'd like to be able to merge changes whenever possible which is not possible just by overwriting the updated files by copy-pasting...
You could put the other repository as a subrepository into yours.
This is not exactly what you requested, since you said that you don't want the history of the other repository, only the last revision.
But as you already noticed yourself, everything else that you tried (pulling the other repository into yours, copying files manually, ...) is a hassle.
With subrepositories, you can just update the subrepository to get the changes tht the others made.
Related
Every time I pull from a repository I get not only the changesets but also all the bookmarks from that repository. In some situations this is quite annoying. Is there a way to pull without getting bookmarks?
(I'm actually using TortoiseHG, but information about plain Mercurial command line is useful and appreciated as well.)
(Background: In TortoiseHG having many bookmarks gets cluttered quickly. That doesn't matter in the remote repository where the bookmarks should remain for future reference. But locally I don't need or want them. So after each pull from the remote repository I have to delete each bookmark individually. This gets old fast...)
I don't think that push copies bookmarks, so why not go to the remote repository and from there push into yours?
Alternatively, .hg/bookmarks is just a text file, what happens if you copy it, pull, and then restore the original?
Is there a way to pull without getting bookmarks?
No. You get all remote bookmarks from remote repository every time
In TortoiseHG having many bookmarks gets cluttered quickly
How?! Not active "external" bookmark will remain invisible in the past history quickly
but... you can rename your local, important bookmarks (give some unique prefix) and after it deleting remote bookmarks after each pull can be a lot easier: grep -v PREFIX for content of .hg/bookmarks file
I inherited a Mercurial repository that includes some directories with binary files.
All of the files in the aforementioned directories were removed from Mercurial a long time ago, and they will never be used again.
I've read that it is difficult to remove files permanently from Mercurial due to changeset hashes.
Is there any way to remove the data, either only from my local repository, or, preferably, from the bitbucket repository, too?
I don't care if the history of these files can remains in Mercurial, I just don't want to waste storage for them.
If I can't remove the files nicely from bitbucket, can I just delete the apropos .i files under .hg/store/data in my local repository? I'd retain the .i files in bitbucket. Would this cause any problems with my local repository, either by itself, or when pulling from or pushing to bitbucket? No one will ever clone from my local repository.
Thanks.
You can't really remove the data, but you can convert and filter a repository with the Convert extension. In your case, convert from Mercurial to Mercurial. See the --filemap option.
I don't think that counts as removing the data, because you end up with a new repository and new changeset ids. But you do end up with a new repository that excludes whatever you told it to exclude.
If you're the only developer, it seems safe to me to replace the existing bitbucket repository with your new one. But I'd test that on a scratch repository, myself. If you're not the only developer, take some time to plan the conversion. (And make sure it's worth the trouble. It's usually not--disk is cheap.)
I suspect this might be really obvious but I can't find a straightforward solution in the documentation or forums:
I have written some code that is held in a Mercurial repository on BitBucket.
I use this code to build Linux virtual servers. When I build a server, I clone the repo onto the server, run my build script, and then delete the clone. The result is a configured server with several files from my repo located in various folders on the server.
Now, I'm looking for a mechanism where I can roll out bug fixes and improvements to my users' servers after I have handed them over. At that time, I won't have SSH access to the servers and I cannot expect my end users to do anything more complicated than kick off a cron job or launch a script.
To achieve this, I'm thinking of setting up a BitBucket account for my users with read-only access to my repo.
I have no problem writing a script to clone my repo, via this read-only account, and apply the updates, but I don't want to include all my files. In particular, I want to exclude my build script as it is commercially sensitive. I know I could remove it from my repo, but then my build wouldn't work.
Reading around, it seems I may need to create a branch or a fork of my repo (which?). Or maybe a sub-repo? Then, I could remove the sensitive files from that branch/fork/sub-repo and allow my users to clone it via a script.
That's OK, but I need a way to update the branched/forked/sub repo as I make changes to the main one. Can this be automatic? In other words, can it be set up to always reflect the updates made in the main repo? Excluding the sensitive files of course.
I'm not sure I'd want updates to be automatic though, so I'd also like to know how to transfer updates from the main to the branch/fork/sub manually. A merge? If I do a merge, how do I make sure my sensitive files don't get copied across?
To sum up, I have a main repo which contains some sensitive files and I need a way to roll out updates of all but those sensitive files to my read-only users.
Sorry if this is hugely obvious. I'm sure it's a case of not seeing the wood for the trees and being overwhelmed by the possibilities. Thanks.
I don't think that you need to solve this in Mercurial at all.
What you actually need is Continuous Integration / a build server.
The simplest solution goes like this:
Set up a build server with something like TeamCity or Jenkins, that's always online and monitors changes in your Bitbucket repository.
You can set it up so that when there's a change in your repository, the build server runs your build script and copies the output to some FTP server, or download site, or whatever.
Now you have a single location that always contains the most recent code changes, but without the sensitive files like the build script.
Then, you can set up a script or cron job that your end users can run to get the newest version of the code from that central location.
You are ok with two branches, one for the users clone (main) and other for your main development (dev), the tricky part is merging the new changes from dev to main.
You can solve this by excluding files in the merge process. Excluding a file while merging in Mercurial
By setting the [merge-patterns] section in your .hgrc you can sepcify what files are not affected by the merge.
[merge-patterns]
build.sh = internal:local
For more info read hg help merge-tools.
"internal:local"
Uses the local version of files as the merged version.
Entire Mercurial trees always get moved around together, so you can't clone or pull just part of a repository (along the file tree axis). You could keep a branch that has only part of the files, and then keep another branch that has everything, making it easy to merge the the partial (in terms of files) branch into the other branch (but merging the other way wouldn't be particularly easy).
I'm thinking maybe subrepositories work for your particular use case.
I am (still) trying to completely migrate our company's SVN to HG.
For the most part I've succeeded, but we ran across a problem.
Our codebase has over 30 different projects, each one on its folder.
I've been asked multiple times how to commit and then push specific files to our central repository instead of being forced to commit everything everywhere to then push it, it's certainly annoying. Not being able to pull only specific projects is also an nuisance.
Is there any way to handle this like we used to in SVN? Where we could just commit what we wanted and not everything, and update only what was necessary.
Thank you.
A major difference between SVN and Mercurial is that you should have one repository per project in Mercurial.
You can change your repository to be multiple repositories using the convert extension.
Like Steve Kaye said you should create one repo per project, but as well you may want to create one master repo and include all your projects as subrepos This will allow svn like behavior of getting a copy of everything.
I have few questions and i would appreciate your help:
Say, i need specific folders from another repo merged into my repo/working dir. How would i do properly?
If i pull anothers repo and then merge. Afterwards, realizing this is not working, so i call 'hg update -C'. Did this cleaned my repo from the changes i pulled from another repo that i released is not what i need?
Can i do a pessimistic merge where it only adds and updates, but not deletes?
Thanks for helping learn Mercurial
Margots
I would just copy the needed files and folders from the other repo and commit them. You could technically do what you want as a merge but it's a manual, error-prone, finicky process.
If you haven't committed your merge update -C will abandon the merge. Do update -C <myVersion> to get the specific version you want.
This would be a messy process (see 1.) and I wouldn't bother. If there are problems you can always revert your file to a previous version.