Obsolete Terminology

[dukeofgaming]

I for one love the idea. This would effectively stop me from looking at git
with hungry eyes whenever I think of having to rewrite history... not that
is something I even want to do, but sometimes it just helps a lot.

Regards,

David

On Wed, Aug 1, 2012 at 7:37 AM, Pierre-Yves David <
pierre-yves.david at logilab.fr> wrote:

> Patrick already wrote a very good reply to most of your objection. I won't
> duplicate it's reply.
>
> On Sun, Jul 22, 2012 at 08:01:06PM -0400, Greg Ward wrote:
> > On 16 July 2012, Pierre-Yves David said:
> > > This email contains as sum-up of content and effect of the obsolete
> markerwhich is currently getting into core. And the current name for every
> concept
> > > that deserve one.
> > >
> > > The main goal of this email is discuss the current naming scheme and
> to improveit until it is perfectly cool and consistent.
> >
> > ...and this is supposed to replace MQ by being *simpler* than MQ? Or
> > by attempting to conceptualize and nail down the entire universe of
> > mutable source control history?
>
> This email was about the underling concept of changesets obsolescence. And
> yes,
> this concept aims to nail down the entire universe of trouble you get when
> exchanging mutable history. The process goes well so far :-)
>
> But of course we wont encourage people to jump into all possible troubles
> their
> can create. UI built atop this concept aims to be simple and should not
> require
> deep knowledge of all possible edge case. Using the evolve extension as a
> replacement for MQ only requires the user to know about:
>
> - obsolete changeset == older version you don't want anymroe
> - unstable changeset == descendant of something you amend that need some
>   automatic fixing.
>
> And we can even imagine stabilizing descendant by default to never expose
> unstability to the user.
>
> All the complexity described in the email is here to provide a consistent
> safety net for people going much further than MQ (or even other DVCS).
>
> > If simpler: sorry, no. MQ certainly isn't perfect. It has a steep
> > learning curve and, like any powerful tool, sharp edges that you can
> > cut your fingers on. But it has a big advantage: its model is simple.
> > After someone has a couple of months' experience with Mercurial, and
> > has demonstrated a basic level of cluefulness, I can explain the
> > concept of MQ to them in 10 minutes.
>
> I can do that too. And probably quicker ;-)
>
>     When you "refresh" the content of a changeset, you actually create a
> new
>     changesets and mark the older one "obsolete". Any descendant of this
> older
>     changeset need to be rebased on the newer version. Until then, their
> are said
>     unstable.
>
> > Instead of "troublesome", I kinda like "troubled". But I am less than
> > thrilled by the number and complexity of concepts being tossed around
> > here.
>
> I'll add "troubled" to the list of alternative. Thank you. Most user wont
> need
> all those possibles case. If they do, they are probably already a bit
> crazy.
>
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlAZIwsACgkQElczi7p/bN/hkwCcCZy30HnP81Vd9LE2rtfeorvq
> rhEAniOkLqgVX+jt57SizfnIEfLeLj34
> =m4lg
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120803/9b797b4f/attachment.html>