New evolve docs, take 2: 1/3: index.rst
Martin Geisler
martin at geisler.net
Sat May 31 09:26:16 UTC 2014
Greg Ward <greg at gerg.ca> writes:
Hi Greg,
I really like the use cases you've written up! The gradual introduction
is very nice (fix mistake immediately, fix it later, ...).
> On 30 May 2014, Angel Ezquerra said:
>> Greg, very nice write up. I have a couple of small comments below.
> [...]
>> > Some of the things you can do with ``evolve`` are:
>> >
>> > * Fix a mistake immediately: "Oops! I just committed a changeset
>> > with a syntax error―I'll fix that and amend the changeset so no
>> > one sees my mistake." (While this is possible using existing
>> > features of core Mercurial, ``evolve`` makes it safer.)
>>
>> I'd say that evolve makes it safE :-)
>
> If there were no such thing as .hg/strip-backup/, then I would agree.
> But strip isn't *completely* reckless or unsafe. It's just that
> obsolesence is *safer*.
I'm actually confused why you would call one safer than the other.
Safety doesn't seem like the diffenting factor to me. Both mechanisms
leave the data behind: strip places the old data in external bundle
files and evolve leaves the data in the repository, but marked obsolete.
Compare 'hg commit --amend' with and without evolve enabled: one leaves
the pre-amend commit in a bundle file, the other marks it as obsolete.
Unless you consider the revlog rewriting done by strip buggy, I think
both mechanisms are "safe", meaning that they both preserve your data.
The big difference for me is the convenience -- no more digging around
in tons of .hg/strip-backup/blabla files! That evolve can amend non-head
commits is another great trick, though you could implement that without
invoking the concept of obsolete markers.
Basically, I think it gives Mercurial a richer model when you can talk
about an obsolete changeset instead of crudely approximating it by "that
changeset over there in the bundle is now obsolete".
Please don't let this block the docs from being integrated. I think
there will be plenty of time to fine-tune the description later and it's
good to get something out there to iterate on.
--
Martin Geisler
http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20140531/edce9974/attachment.asc>
More information about the Evolve-testers
mailing list