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 facility, I can do all my changes in my local repo and do an "hg push" to send the changes back to bitbucket.

Don't I need to follow this "hg push" command run on my local machine with an "hg update"?

Answer 1

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.