I and another guy needs to share a named branch but it is not supposed to be seen/pulled by third party until it is ready. Is there a way to push a branch only between us?
Thanks
There is no easy built-in way where you can share changesets and still not accidentally push them to a central server.
What I would do would be to clone the repository into a separate place and use that as a synchronization point.
Let's say you're using bitbucket, and want to work on some changes before making them available to the public. You would clone the repository to a private repository, giving you both access, and you could push and pull with that central repository to your hearts content. At some point you're ready, and then you push to the public central repository and delete the private one.
You could also set up local clones where you can push and pull between you, but not push to the central repository.
Here you would clone the repository on your local machines, and then change the .hg\hgrc file to point to your friends repo, so that you can both pull and push with each other. At some point you would then use hg push url-to-central-repo to push to the central repo and share your changesets.
There is also the use of the phase system you could use, but in this case it would add some hassle that I'm not sure you would like. Basically you would flag your changesets as secret, which will prohibit them from being pushed. However, in order for you to push your changesets to your friend, you would have to temporarily change their phase, push, and then change it back. You could use the batch file from this Stack Overflow question to help out: Push secret changesets.
I would recommend you go with the central private repository. Easier to set up, doesn't involve having to push and pull between computers potentially behind firewalls and routers, and gives you all the power you're used to from your normal central repository.
Related
Is it possible to react to a push to a repository with a hook and merge all new heads that are created by this push?
My use case for this is the following:
I'm trying to design a repository that would only allow very specific changes with a commit hook. The basic idea is that it is only allowed to replace existing files with better files (better is something that can be checked by an external program). Each user could clone a central repository and commit changes to the clone. When a user pushes his changes to the central repository, a hook checks whether the quality increases along each branch and rejects the push otherwise. If users push out of sync, this will create multiple heads that could in theory be merged automatically (taking the best version of each file).
Your hook can do whatever you want, in principle. Write a program that handles the evaluation and merging you describe, and associate it with the changegroup hook, which is triggered whenever someone pushes a group of changesets to the repo, or the incoming hook, which is executed separately for each arriving changeset.
I recently had to make a couple of changes which required rebuilding the repository using hg convert. Unfortunately, this means the bitbucket repo is now inconsistent with the copy I have locally. I don't want to just "blow away" the repo as it exists on bitbucket, because that gets rid of all the other customizations / issue tracking etc. that are associated with the project there.
Is it possible to completely wipe the repository from Bitbucket's view of things and push everything from my local (fixed) repo there?
You can strip the changesets from the Bitbucket repository. Go to
https://bitbucket.org/<user>/<repo>/admin/strip
and you'll get a chance to enter a revision to strip. The revision number you enter plus all its descendants will be deleted from Bitbucket. So if you enter 0, then all changesets will be removed from the remote repository.
This brings you back to the clean slate you had when you first created the repository on Bitbucket and you can now push your code again.
The settings for the project remain intact (issues, wiki) and any existing forks also remain. People who've forked your project will have to do the same strip operation — you have to coordinate this with them and this is the reason why editing history is hard. Bitbucket warns you about this by telling you the number of works right on the strip admin page.
A picture is worth a thousand words.
I am writing a open source project, I did all the work at my machine and now I want to push the project do Codeplex.com, but I dont want to send all the old history.
Its possible to push all files in just one revision to Codeplex and continue with my history locally? Something like a Push And Collapse
No - a DVCS relies on the fact that you synchronise all history between members in the distribution set.
If you want to get rid of the history though, prior to pushing to Codeplex you can do the following:
Clone your local repository to a revision before the history you want "removed". We'll call the clone "Repository B".
Update repository A to the tip that you want to apply. Grab the changes, and copy the files to your cloned repository B. You can greate a bundle or patch, but for brevity here I'm just going with the quick and dirty :)
On repository B, commit a single changeset with all those changes.
From now on, repository B is your master. Push this to Codeplex.
As you can see, you can't have historical changeset data on one clone that partakes in a synchronisation with another, but before you've pushed to Codeplex, you can mush all those changes into a single commit - so long as you're happy to lose the history locally too.
An alternative is to use Mercurial Queues to "fold" history, but it needs to be done before you push to Codeplex - check out this wiki page for more information.
Check out the CollapseExtension.
Using a Macbook, I am worried that if the hard drive is on the road and it goes bad, then 3 days of code can all be lost.
So I actually have a tmp repository on our main server computer, and I can hg push to it. The dilemma is, I can't push unless I commit first, and from previous experience, we shouldn't commit unless we are ready to push to a central server (to share code with coworkers, merge, etc) (the reason is, we can't push selected files -- we have to push all committed files or push nothing). So how to solve this?
Is there a way to say, "copy all MODIFIED FILES (and added files) to /user/peter/2010-06-18 on the central server?)" or not commit but somehow get it onto the server?
The normal way is to just commit. With a DVCS one is urged to "commit early, commit often". Commit locally often, then for backup purposes push to your tmp repo on the server frequently. When you're happy with your work, then you push from your tmp repo to your shared "central" server.
There's no need to make sure everything compiles after each changeset, the norm is to just make sure that each back of changesets you push leaves the 'tip' in a compileable state. Generally one triggers the continuous integration build server to turn a builds after each group of changesets (changegroup) arrives, and it only considers the 'tip'.
If you really, really can't stand having changesets that can't stand on their own, then a mercurial pro would use mercurial queues to keep a versioned patch pushed to a separate queue repository while working on it. Someone willing to play with fire would use the collapse extension to merge the sequence of changesets into a single changeset before pushing to the shared repos.
Of the three options presented:
fix your workflow so that the central repo can handle changesets that don't compile, so long as they're part of a changegroup that compiles
use mercurial queues to keep a patch in a versioned patch repository
use the collapse extension to rewrite history (play with fire)
I think the first is most commonly done, and generally the "right" way.
I created a branch on my local Mercurial repository. I want to push to the shared repository so my work can be backed up, but I don't want other project members to see the branch.
What's the standard operating procedure in this case?
I'd like to avoid having the repository get full of developer branches that I don't need to see.
It sounds like you're conflating two issues. If you need your branches backed up, simply clone your local repository someplace else that is actually backed up, but not visible to your coworkers (that is, not the main repository). You can always easily pull changesets from more than one repository in case that becomes necessary.