Can't commit any changes?

[Martin Geisler]

Ray Bartlett <rbartlett at 20miletech.com> writes:

> [...] "To use Mercurial, you need three things: a repository, a
> .hg/hgrc file, and a clone. The repository is the original source, the
> clone is where the changes are made..." etc.

Maybe the glossary will help you nail down the concepts:

  http://selenic.com/hg/help/glossary

> Take the http://mercurial.selenic.com/wiki/SharedSSH page, for
> example.

I'm afraid that is a bad example -- don't start with complex stuff like
that. Mercurial and SSH is super easy assuming you are already familiar
with SSH... and that page seems to assume that.

> It's not a page that steps someone through the process of setting this
> up. It's just a listing of different elements that relate to
> SharedSSH. The same with many of the Tutorials I've seen. The quick
> start, followed to the letter, didn't mention anything about setting
> up a proper .hg/hgrc file, which is apparently vital. Then when
> running Mercurial, I got an error (not mentioned in the Quick Start)
> that turns out to be because I have to add a username to the .hg/hgrc
> file (as in [ui] username = me <foo at foo.com>). But it still didn't
> work.

Okay, I agree that it's quite unfortunate that you get errors and output
that differs to what the tutorial says. The guide I made here avoids
that problem by double-checking all the examples when I upload the HTML
files:

  http://mercurial.aragost.com/kick-start/en/basic/

The examples are most recently compiled with Mercurial 1.7.

> Am I right to understand that without a line in the .hg/hgrc file
> specifying a path, no changes will ever get back to the central repo?

Almost... the key is that 'hg push' can take an argument on the command
line. So you can do

  hg push

and Mercurial will then look in .hg/hgrc for a [paths] section and use
the default path configured there. Or you can do

  hg push http://server/my/repository

and Mercurial will push there. See 'hg help paths' for some info.

> And am I right to understand that while yes, Mercurial doesn't have a
> "central" repo, since we need one, we can achieve something similar by
> having people clone from and push to the same place, so that each time
> someone's cloning it's always the latest version?

Yes, exactly. Technically, there is no central repository, but in
practise there always is by convention.

> [...] On Thursday, it's a snow day, so people are at home. Person A
> and B both decide to work on the same project, but thanks to our use
> of Mercurial, this doesn't mean that Person B's changes are lost when
> Person A pushes his work back to /var/www/html/lasersharks. Instead,
> the changes of Person B and Person A get merged (presumably by "hg
> merge" on the dev server?)

Almost -- the merge is not done on the server, but instead done locally
by the developer who pushes last. When Person A pushes, he will be told

  $ hg push
  pushing to /var/www/html/lasersharks
  searching for changes
  abort: push creates new remote heads on branch 'default'!
  (you should pull and merge or use push -f to force)

As Mercurial suggests, the right action is to do

  $ hg pull
  pulling from /var/www/html/lasersharks
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  (run 'hg heads' to see heads, 'hg merge' to merge)

followed by

  $ hg merge
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)

and after a checking that things work, Person A commits the merge:

  hg commit -m 'Merge with Person B.'

This is described here (albeit in the other direction where Alice pulls
instead of pushes):

  http://mercurial.aragost.com/kick-start/en/basic/#divergent-lines-of-development

The screenshots there (should) show what is going on.

After Person A has done the merge locally, he can now push to the
central repository and Mercurial wont complain since he is no longer
creating any new "heads" (see the glossary).

> Again, I appreciate people's time.  Sorry if I sound down about this
> -- as someone (maybe Mike?) suggested, once I'm up and running it will
> all make more sense and be easier than I think.  But compared to so
> many open source projects I've used, boy, the learning curve here has
> been steeper than I expected.

Don't worry, it will all fall into place... you are certainly right that
the guides assume that the user already uses some other revision control
system, frankly because that's how most developers work. So the guides
focus on how to do things with Mercurial and maybe not as much on why
you would want to do them -- they just assume you know why :)

So yes, there is a lot of new concepts, especially if you start from
scratch. Start with the basics: make a repository, make some commits,
view the log. Then examine how you can clone the repository on your own
machine and how you can push/pull between the two. When you have a good
understanding of the basic commands, then move up to working with
others. This is basically what my kick start guide tries to do :)

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/