stymied by default update

[Ben Schmidt]

>>> Ah, I think I see the rookie mistake (for the record, I wasn't working
>>> with any other repo) --
>>> I've gotten into the (bad?) habit of running:
>>> $ hg update null
>>>
>>> .. I suppose for the sake of starting from a clean slate in the working
>>> directory.

This is most certainly not the way source code management is intended or
designed to work. You never start from a clean slate; your project
evolves as you change it. Your working directory is where your actual
project lives. It's where you do your compiling, debugging, processing,
everything. Version control just slots 'seamlessly' into your existing
workflow. You don't have to do anything different with your files to use
version control; you just have to use a few 'hg' commands while you're
working.

> Yes, thanks for that explanation Matt, I'm beginning to see the subtleties now of
> properly managing the working directory.  I veered off the path conceptually by
> regarding the working directory vis-a-vis the repo as a sort of locale for total
> swap-outs between changesets, obviously disregarding the possibility of merges,
> which I need to do now to get back to par.

To be honest, if you've only got four or so changesets in the
repository, and half of those are wrong, it might be better just to
start again. hg update to the different revisions in your existing repo
to access the files, copy them into the working directory of a new repo
as appropriate, and do the version control correctly.

> So rather than look at the working directory in such an absolute sense, I should
> be content to persist tracked files in the working directory, and
> merge/revert/update as-necessary with the occasional '--clean .'

Not sure if this explanation is helpful, but when you hg commit,
Mercurial will:

- add files to the repository that you told it to with hg add
- remove files from the repository (but not from history) you told it to
   with hg rm
- WORK OUT FOR ITSELF which already-tracked files were modified, and put
   the changes in the repository

To see what hg commit is going to do, you can use hg status. It will:

- show A for files you indicated with hg add (or hg mv or hg cp)
- show R for files you indicated with hg rm (or the origin of hg mv)
- show M for files Mercurial has identified as modified
- show ? for files Mercurial doesn't know about--you can choose to hg
   add them (if they are part of the project), modify .hgignore to hide
   them from this list (if they are not part of the project, and
   unimportant enough that developers don't need to be aware of their
   existence, e.g. automatically generated files, temporary editor files,
   etc. which many/most/all developers will have in their working
   directories), or just ignore them yourself (files not appropriate to
   add or ignore)
- show ! for files that 'disappeared'--you can choose to hg rm --after
   them, or get them back with hg revert

Perhaps this helps.

Smiles,

Ben.