stymied by default update

[John Turner]

On Wed, 31 Dec 2014 08:32:20 -0500, Ben Schmidt  
<mail_ben_schmidt at yahoo.com.au> wrote:

>>>> 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.

Yes, indeed - thanks for the additional perspective and technical  
references, Ben.  As you can probably tell, not just Mercurial, but  
version control in general is a new universe for me.  But I'm glad I  
started with a 3rd generation SCM :)

Cheers,
John