bitbucket, “hg push” and “hg update”

Question

If I start out with a local mercurial repo, which I consider to be the \"main\" repo (pardon me my dvcs lords), and intend to use bitbucket as a backup and issue tracking facili

Answer 1

Bitbucket shows you the repository. As pointed out by Dave Webb, hg update is concerned with updating the working copy. When you do hg push you are transferring changesets in order to update the repository on Bitbucket -- and so the webinterface will show this.

There are no working copies on Bitbucket, as pointed out by Steve Losh. There is also no hg update being done behind your back.

You can experiment with this yourself by making a clone without a working copy:

% hg clone --noupdate repo repo-empty

then go into repo-empty and do hg log. You will see that even though there are no files there, the history (i.e., the repository) has still been cloned. You can make the files appear with the hg update command:

% hg update

and disappear again with

% hg update null

The working copy is only needed if you want to look at the files and make new commits. Otherwise you can remove it to save space. This is normally done in clones that are only used for serving with hg serve or the equivalent thing that Bitbucket uses.

Answer 2

Why do you care what's in the working directory on BitBucket's servers? As long as you push the changes will be in the repository and visible on the BitBucket page.

EDIT: OK, I'm going to edit this to be a useful answer.

Say you clone down one of my repositories like django-hoptoad on BitBucket. You'll have a folder named django-hoptoad on your local machine and its content will look something like this:

django-hoptoad/
 |
 +-- .hg/
 |
 +-- ... my code and other folders

All the data about the repository itself is stored in the .hg/ folder. That's where Mercurial keeps the data about which files were changed in which changesets, and lots of other stuff.

You can think of it like this (though it's an oversimplification):

django-hoptoad/
 |
 +-- .hg/
 |    |
 |    +-- data about changeset 1
 |    +-- data about changeset 2
 |
 +-- ... my code and other folders as they appear in changeset 2

When you run hg pull and don't update, you pull any new changesets into the repository:

django-hoptoad/
 |
 +-- .hg/
 |    |
 |    +-- data about changeset 1
 |    +-- data about changeset 2
 |    +-- data about changeset 3 (NEW)
 |    +-- data about changeset 4 (NEW)
 |
 +-- ... my code and other folders as they appear in changeset 2

If you don't update, the ... my code and other folders will still be equivalent to whatever is in changeset 2, but the other changesets are still in the repository.

When you run hg update Mercurial will update the ... my code and other folders to the contents of the newest changeset.

django-hoptoad/
 |
 +-- .hg/
 |    |
 |    +-- data about changeset 1
 |    +-- data about changeset 2
 |    +-- data about changeset 3
 |    +-- data about changeset 4
 |
 +-- ... my code and other folders as they appear in changeset 4

Really, this means that what happens to be in ... my code and other folders doesn't have to match what's in the repository. You could just delete it and all the changesets would still be in the repository:

django-hoptoad/
 |
 +-- .hg/
      |
      +-- data about changeset 1
      +-- data about changeset 2
      +-- data about changeset 3
      +-- data about changeset 4

If you committed right now, it would create a new changeset that basically says "no files". You don't have to commit though. People can still push and pull from you because the repository still has all the data about the changesets.

This is almost certainly what BitBucket is doing. You're never going to log in to BitBucket's servers, edit your code and commit there -- you're only ever going to push/pull/clone. That means the ... my code and other folders will never actually be used, so I'd imagine Jesper has it set up to delete it to save the disk space.

Since hg update only really affects the working directory, and the working directory on BitBucket is never used, you don't need to run hg update after you push to BitBucket.

Answer 3

I think you might be getting confused between the working copy (aka working directory) and the local repository. These are related but separate things. The local repository contains the full history of all tracked files whereas the working copy contains versions of the files from a particular revision plus your changes to them,

The hg command push and pull move changes between repositories and update and commit moves changes between your working copy and your local repository.

So if you push changes to a remote repository that will not change the local repository and so there's no need to run an update on the local repository. However, anyone using the remote repository will need to do an update so your changes are shown in their working copy. Conversely, if you pull changes from a remote repository you will need to do an update so that these changes are shown in your working copy.

Similarly, you need to commit all changes from your working copy into the local repository before they can be sent to another repository using push.

Answer 4

No need to do a hg update on your local machine. Update is used when data is pushed TO your local repository, and you are pushing FROM your local repository.