Multiple undo again...

[Gilles Moris]

On Friday 04 June 2010 09:54:54 pm Jason Harris wrote:
> On Jun 4, 2010, at 9:46 PM, Gilles Moris wrote:
> > On Friday 04 June 2010 05:15:49 pm Jason Harris wrote:
> >> But sorry what I was planning to do was:
> >>
> >> something like for initialization:
> >>
> >> export HGDIRNAME='.hgbackup'
> >> hg init
> >> hg addremove *
> >> hg commit -m "initialize undo / redo"
> >>
> >> Then when I needed to backup something like:
> >>
> >> export HGDIRNAME='.hgbackup'
> >> hg addremove *
> >> hg commit -m "do a backup step"
> >>
> >> So where in this process should I do the cp -al
> >
> > I would certainly not want that in mercurial.
>
> Well it certainly wouldn't be by default on.
>
> > I like HG because it's lightweight and this does not seem to go in the
> > right direction IMHO.
> > What you're proposing seems just too much to me.
>
> Thanks for your comments though :) !
>
> I still feel its sometimes too easy to stuff up. Just see the other recent
> thread a couple of minutes ago, about patch queues and possible data loss.
> Basically, I want to be able to undo more than one time. Thats the goal.
>
> How its implemented is of course secondary...  So the question is do you
> not even want that goal of being able to undo a couple of operations, or
> its just that having an environment variable HGDIRNAME is of no interest to
> you? Its cool if it isn't... :)
>
> Cheers & thanks,
>   Jas

I don't feel any need for this: DVCS allow to commit as much as you want 
locally and this actually brings this additional security that I can update 
to any of those commit. HG is safe by default without extensions. And 
absolutely don't want HG to track the other files lying around which consist 
in MB or GB of binaries, libraries and other iso stuff.

Now mq is destructive when you do a qrefresh and does not keep it's history. 
That's the reason why it never made it into the core. That's also the reason 
why I am not using it when I am doing something experimental and that I use 
the "commit often" policy. I can still collapse all my changesets into one 
when I'm done and push only this nice changeset in the end. Something that 
cannot be done with a centralized VCS.
Moreover, though I have never tried it, pbranch would be a more secured 
alternative to mq, as it will keep the whole history.

With all that, I don't think much more is needed. You can bring a cron commit 
with MacHG. Or mq could keep the n latest versions of a patch. But I don't 
expect more. And surely "hg addremove *" is a no-go.

Regards.
Gilles.