[prev in list] [next in list] [prev in thread] [next in thread]
List: mercurial
Subject: Re: Why bare 'hg update' needs behaviour change
From: James Reynolds <eire1130 () gmail ! com>
Date: 2016-12-21 14:21:19
Message-ID: CAE0jAbp+nK=g8poz4AFAQJzVTn3JAD9HZqDyXkGBz7Psm5iqDw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I brought this topic up a few months than ago.
I also wrote a patch, unsubmitted, that did what I proposed. (Also, why
can't mercurial use pull requests, rather then email patches? Do any
organizations really work by emailing patches around? Maybe if mercurial
did, users would realize the problems with bookmarks in practice)
1. Added a setting that changed the behavior of hg up to be predictable.
2. The setting is opt-in. No setting =old behavuor.
I liked this because it opened the door to a reasonable depreciation policy.
However, two things happened.
1. The "change" camp felt this was too much work in large teams (to add
just one line item to an hgrc).
1.b the "remain" camp are purists and like the behavior as is and prefer we
should all be purists.
2. The small minority remaining then went down the rabbit hole of "let's
name this setting variable!"
That's about when I gave up.
Anyway, I'm happy to submit the patch if there is interest.
James
On Dec 21, 2016 3:04 AM, "David Demelier" <demelier.david@gmail.com> wrote:
> 2016-12-20 23:25 GMT+01:00 Marcin Kasperski <Marcin.Kasperski@mekk.waw.pl>
> :
> > Leaving apart the general design discussion: in such a scenario I would
> > seriously consider using SINGLE named branch, called experimental (and
> > various bookmarks and heads on this branch to mark actual work items) –
> > plus merging finished work to default (and merging default back to
> > experimental to keep it up to date). This avoild pollution of maaany
> > named branches, but clearly separates development from stable and keeps
> > hg update sane.
> >
>
> To me default is already a branch for development. It's even
> recommended to develop on this branch. I use stable branch and
> releases branches where only "safe" revisions are committed/pushed.
>
> > Regarding general thing, I think that there is more promise in making
> > branches sane (able to fade away, then disappear) than in making
> > bookmarks sane (able to stay where they should and cooperate with update
> > properly). Those sane branches are to be called topics IIRC, not sure
> > how far advanced is the work on them.
>
> Topics are nice but you can't share them unless you make a
> non-publishing server which to me is not an option.
>
> --
> Demelier David
> _______________________________________________
> Mercurial mailing list
> Mercurial@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>
[Attachment #5 (text/html)]
<div dir="auto">I brought this topic up a few months than ago.<div \
dir="auto"><br></div><div dir="auto">I also wrote a patch, unsubmitted, that did what \
I proposed. (Also, why can't mercurial use pull requests, rather then email \
patches? Do any organizations really work by emailing patches around? Maybe if \
mercurial did, users would realize the problems with bookmarks in practice)</div><div \
dir="auto"><br></div><div dir="auto">1. Added a setting that changed the behavior of \
hg up to be predictable.</div><div dir="auto">2. The setting is opt-in. No setting \
=old behavuor.</div><div dir="auto"><br></div><div dir="auto">I liked this because it \
opened the door to a reasonable depreciation policy.</div><div \
dir="auto"><br></div><div dir="auto">However, two things happened.</div><div \
dir="auto"><br></div><div dir="auto">1. The "change" camp felt this was too \
much work in large teams (to add just one line item to an hgrc).</div><div \
dir="auto"><br></div><div dir="auto">1.b the "remain" camp are purists and \
like the behavior as is and prefer we should all be purists.</div><div \
dir="auto"><br></div><div dir="auto">2. The small minority remaining then went down \
the rabbit hole of "let's name this setting variable!"</div><div \
dir="auto"><br></div><div dir="auto">That's about when I gave up.</div><div \
dir="auto"><br></div><div dir="auto">Anyway, I'm happy to submit the patch if \
there is interest.</div><div dir="auto"><br></div><div dir="auto">James</div><div \
dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On \
Dec 21, 2016 3:04 AM, "David Demelier" <<a \
href="mailto:demelier.david@gmail.com">demelier.david@gmail.com</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">2016-12-20 23:25 GMT+01:00 Marcin \
Kasperski <<a href="mailto:Marcin.Kasperski@mekk.waw.pl">Marcin.Kasperski@mekk.waw.pl</a>><wbr>:<br>
> Leaving apart the general design discussion: in such a scenario I would<br>
> seriously consider using SINGLE named branch, called experimental (and<br>
> various bookmarks and heads on this branch to mark actual work items) –<br>
> plus merging finished work to default (and merging default back to<br>
> experimental to keep it up to date). This avoild pollution of maaany<br>
> named branches, but clearly separates development from stable and keeps<br>
> hg update sane.<br>
><br>
<br>
To me default is already a branch for development. It's even<br>
recommended to develop on this branch. I use stable branch and<br>
releases branches where only "safe" revisions are committed/pushed.<br>
<br>
> Regarding general thing, I think that there is more promise in making<br>
> branches sane (able to fade away, then disappear) than in making<br>
> bookmarks sane (able to stay where they should and cooperate with update<br>
> properly). Those sane branches are to be called topics IIRC, not sure<br>
> how far advanced is the work on them.<br>
<br>
Topics are nice but you can't share them unless you make a<br>
non-publishing server which to me is not an option.<br>
<br>
--<br>
Demelier David<br>
______________________________<wbr>_________________<br>
Mercurial mailing list<br>
<a href="mailto:Mercurial@mercurial-scm.org">Mercurial@mercurial-scm.org</a><br>
<a href="https://www.mercurial-scm.org/mailman/listinfo/mercurial" rel="noreferrer" \
target="_blank">https://www.mercurial-scm.org/<wbr>mailman/listinfo/mercurial</a><br> \
</blockquote></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
Mercurial mailing list
Mercurial@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic