We have some restrictions on what we are allowed to put in our central Mercurial repository.
Is there some way I can keep stuff in my local Hg repository, without having it pushed to the central one?
Note:
The files might be connected to files in the central repository (branches for example).
Local stuff might later be incorporated in the central repository.
If you're using branches, you can set their visibility to secret. This will prevent them to be pushed.
hg phase --secret --force my-branch
When you want to share, you change their phase to draft and then they will be automatically collected during a push operation.
See hg help phases for more information.
You could also use Mercurial Queues. With MQ, you can work with patches (which are changesets) and update or re-order them based on changes in the official repository. This will also make it easier to incorporate some or all of your changes into the main repository or just discard them later.
Commit to your local repo, then push to the remote repo when you are finished.
You can push to your local repo as well, but from my understanding that is where your current development is?
I think you want Shelve Extension or Attic Extension.
The other option is if your using a newer Hg with better branching you can just fork the central repo somewhere like bitbucket and use that as your repository for your temporary stuff and potentially branch that.
Finally you could also just use .hgignore but that could be problematic later when someone does check in the file with the same name.
Related
I use two mercurial repositories, one for the current stable version and one for new development. I accidentally developed a new feature inside the current stable repo and now I want to commit the changes to the new dev repo and not to the current stable repo. Is there a way to do this? I have not committed any of my changes yet.
Use
hg diff >changes.patch
To create a patch of your changes. Then, go in the other repo, update where you need your changes to be, and issue
hg import --no-commit changes.patch
With the proper folder to changes.patch You should then be at the same place you were on the other repo, too.
However, if both repos are equivalent, whether you commit and push your changes from the current repo or the other, they could eventually be replicated on both, so think about the necessity of moving the changes across repos. Use branches to handle different feature development.
I have a remote hg repository hosted on googlecode. Thus I don't have admin access to run e.g. lfconvert on it (as far as I know), and of course lfconvert can only be used on local repositories.
So, is there any way to a convert an googlecode hg repository to a largefile repository?
(one idea is to convert a local clone of the repo to a largefile repo and then push the changes to the "central" googlecode repo, but I fear trying that without knowing if it is a valid approach).
Using your idea to do a local conversion and push, you can take advantage of the 'reset' feature for your repositories:
Do a local clone.
Convert to largefiles: `hg lfconvert normal_repo largefiles_repo``. Do NOT delete the original clone until you are sure everything works.
Reset the hosted repository (See https://code.google.com/p/support/wiki/MercurialFAQ#Mercurial_FAQ).
Push the largefiles repository.
Pushing the largefiles repository without reseting seems problematic because the largefiles repository is essentially a fork of the original one starting at the point the first largefile was committed.
If the push fails*, you can push the original clone and you'll be back where you started without any data loss. (One of the many advantages of DVCS. :-))
The big downside of course is that everybody who has ever cloned your project will now be working from a different fork of the repository. This is always a danger when you do anything involving changing history and is the motivation for Mercurial phases. If you want to be 'kinder', you can start a second project for the largefiles version and place a link at the original project cite describing the move.
[*] I can't figure out from Google Code's documentation whether the largefiles extension is supported. There is a reviewed feature request, but I couldn't find any mention of the request actually being implemented. The push failing would probably be a good indication that largefiles isn't supported though...
When I type hg outgoing, I get a response like this:
comparing with ssh://server:1234/path/to/repo
and a delay while it communicates over the network.
Why is this network traffic necessary? Is there something fundamental about Mercurial which means it can't remember which commits have been pushed, and which haven't?
Is there an alternative command which can give me similar information without having to communicate over the network?
As Mercurial is a distributed system, there are multiple ways for your changes to get from your local repo to the remote repo.
For example:
it is possible for someone to pull changes from you and then push those changes to the remote repo
you could actually just copy your local repo using whatever operating system you have and Mercurial would be totally unaware of that. You could then push the changes in this copy to the remote repo.
However, if you have Mercurial 2.1 or later you can use hg phase to determine which changesets have been pushed. Assuming you don't use hg phase to change the status of any changesets then the changesets with a phase of draft or secret have not been pushed and those with a phase of public have. Use
$ hg log -r "not public()"
to see unpublished changesets.
It won't catch the two examples I gave above but it will probably be good enough if you just want to know which changesets you have not pushed.
Look here or check hg help phases for instructions on how to work with phases.
A mercurial repository can potentially connect with multiple other repositories. So, I guess it needs to make sure the changes that weren't pushed from your repository, didn't arrive from another repository already.
I use named branches in Mercurial.
In doing so I have created one branch called playground where I can try out various wacky experiments. I never intend to merge this branch into any others and I never want to push it to our main repository.
Since creating it, every time I do a push I am told I have added a new branch and I have to use the --new-branch flag. At this point hg push -b default (or whatever branch I'm pushing) works fine but it's annoying. Is there any way to suppress that message by letting Hg know that I am not interested in pushing that branch ever?
Starting with Mercurial 2.1 (released in February 2012), you can mark your changesets secret to keep them from being pushed to another repository. You use the new hg phase command to do this:
$ hg phase --force --secret .
This mark the current working directory parent revision (.) as being in the secret phase. Secret changesets are local to your repository: they wont be pushed or pulled. Pushing now looks like this:
$ hg push
pushing to /home/mg/tmp/repo
searching for changes
no changes to push but 2 secret changesets
There is no equivalent mechanism in older versions of Mercurial. There your best bet is to create a local clone for the changesets you don't want to push.
Update:
Mercurial 2.1 introduced the hg phase command which allows users to control what change sets are exchanged with remote repositories. #MartinGeisler answer to this question details this method.
Original Answer:
If you want to create a local branch of your code you have a couple options. You can hg clone the repository which will locally create a branch of the entire repository in your filesystem. The other alternative is you can try to use a Mercurial extension like LocalbranchExtension.
There are many ways to branch in Mercurial without using a named branch. Just find a method that suits your needs.
Further reading: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
In addition to the excellent answer above concerning phases, you can also specify 'default-path' (in the [paths] section of your .hgrc) to refer to the local repository:
[paths]
default = ...
default-push = .
This will cause all outgoing changesets to be compared to the specified repository. In this case, comparing outgoing changesets in your local repository TO your local repository results in nothing to push.
You can still pull/update/merge from the main repository, but no push will ever send anything back to that main repository.
If you work on multiple machines/repositories, you can set one up as described above, and configure the others to specify the 'default' path to point to the server that pushes to itself. In this way, the other machines can push/pull to your local central repository, and these changesets will never escape your carefully configured collection of repositories.
I have a project where I'm using Bitbucket as my HG server, but I've recently discovered that as a lone developer I can use Fogbugz/Kiln for free. I want to move my files into Kiln but I don't want to lose my history. I'm sure there's a dead-stupid easy way to do it, but I just don't know. How do I do this?
Thanks!
Create the new project repo and do the following with your current copy of the original repo: hg push new-repo-path.
Then you use the new path in the future. You can delete the bitbucket repo.
With Mercurial, all history is in every copy of the repository, including your local copies.
Since you are already using Mercurial. I was just curious, shouldn't cloning your repository on Fogbugz/Kiln be sufficient.
hg clone "BitBucket Repo ..."
Of course, this won't copy your per-repository hgrc file. You will need to do that separately.
Another approach is to use bundle.
hg bundle --all bitbucket.bundle
hg clone bitbucket.bundle my_repo
Third approach is to push or pull from bitbucket repo to fogbugz repo.
Setting defaults
See: https://www.mercurial-scm.org/wiki/TipsAndTricks.
Reproducing it here:
It is possible to store a default push URL that will be used when you type just 'hg push'. Edit hgrc and add something like:
[paths]
default-push = ssh://hg#example.com/path
The other answers have already explained that right after creating a new empty repository, you can push your changes into it with hg push http://example.com/hg/newrepo. (Note that once you have pushed some changes into it, it will only accept changes from related repositories in the future.)
What you also seem to be wondering about also is how to then configure your local repository to push to that location by default, without needing to specify the URL every time. You can do that by editing the default location in the .hg\hgrc file of your repository. It is a text file that you can open with notepad or any other text editor.