On Sat, Feb 14, 2015 at 9:21 AM, Ted Mielczarek <t...@mielczarek.org> wrote:
>
>
> On Fri, Feb 13, 2015, at 11:43 AM, Nathan Froyd wrote:
> > On Fri, Feb 13, 2015 at 1:40 AM, Gregory Szorc <g...@mozilla.com> wrote:
> >
> > > Truth be told, unless you are collaborating with other people using
> > > evolution, the benefit of enabling obsolescence on user repos is
> probably
> > > marginal. The bigger wins come from enabling obsolescence on the main
> > > repos. For example, when your push to MozReview gets landed by
> Autoland,
> > > Autoland can write an obsolescence marker so the next time you pull
> > > mozilla-central, your client will automatically clean up your old
> pushed
> > > commits that have since been rebased and landed. No manual
> branch/bookmark
> > > management necessary: Mercurial automatically sees the old commits have
> > > "evolved" and it hides them from you. It's "next generation" version
> > > control and I can't wait to experiment with time-saving workflows
> which it
> > > will enable.
> >
> >
> > On long-lived git branches that might have several bugs pending in them,
> > I
> > can do:
> >
> > - push some changesets to inbound;
> > - wait for them to merge to central;
> > - pull central and rebase;
> >
> > and those pushed commits are "hidden" from me as well; they no longer
> > appear in the log from central to HEAD. I don't understand why this
> > feature is so groovy.
> >
> > Is the scenario that is interesting really:
>
> I believe the scenario gps is envisioning is actually:
>
> - push some changesets to mozreview
> - autoland rebases and lands those changesets on central
> - you pull central and your original changesets are obsoleted
>
Pretty much. In this world, your VCS tool handles more of your workflow so
you can spend less time banging keys into your terminal and more time
actually getting work done.
The other real advantage of obsolescence/evolution is that it allows
distributed history rewriting. Limitations in VCS tools to recover from
divergent heads / force pushes leads to tools imposing workflow limitations
("push -f considered harmful"). Tools should cater to your workflows, not
impose them. With evolution, if someone else force pushes a branch/head you
are working on, Mercurial knows what happened and can rebase and
cherry-pick as appropriate to recover from it. In other words, history
rewriting in a distributed workflow becomes more viable. As someone who
rewrites history a lot, I love this flexibility to work on my terms,
without putting undue hardship on others.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
