OpenJDK (Java) migrating from Mercurial?

[Malcolm Matalka]

Bob Hood <bhood2 at comcast.net> writes:

> On 11/18/2019 7:17 AM, Malcolm Matalka wrote:
>> There is also "safety in numbers" when it comes to git.  Meanwhile, us
>> in the hg world can't even agree on the best way to make a branch.
>
> Why must there be a "best way"? You've had several approaches laid out for you
> in this thread with regard to Mercurial--certainly more than git offers--and yet
> you can't accept it because there are /too many/choices? Choose the approach
> that best works for your particular situation. How do you know which that is?
> You'll have to discover that for yourself. We cannot possibly know the depth
> and details of your day-to-day operation, and what approach would represent a
> "best practice" for it.

There need not be, as mercurial exists now with out it.  And as I said
in the paragraph right below the one you quoted, if that is the decision
of the community then at least so be it.  I am pointing out that there
is a consequence to that: many people want to clone a repo, make a
change to it, and get it merged back in.  And for many people,
especially in an office setting, that requires making some kind of
branch.

So if the second most frequent thing one will probably do in a repo
(committing hopefully coming first), has uncertainty around it and
requires some serious thought and research to make the right decision,
on top of which since branches are permanent, making the wrong decision
runs the risk of being a forever-mistake, I think the reluctance is
understandable.

Many of the responses in this thread focused on what is great about hg,
and I agree that those things are great.  But I also think it's worth
considering what is bad about it because if people don't ever get to the
point of using those great tools because of the bad things, then it's
not a very strong selling point.



>
> You're the CTO: You are the one who /provides/the guard rails. You're going to
> have to skirt a few edges before you can figure out where they need to be
> placed.
>
> I know whereof I speak: I'm Director of Engineering. It's part of the job.
> For my situation, using named branches provides us with clear demarcation of
> existing releases, and work-in-progress, of a public-facing commercial product.
> Somebody else may have a crew or a project more suited to using bookmarks, hence
> that would be the better way for them to manage.Mercurial gives you the
> flexibility to fit your situation, as long as y/ou/ can define it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191119/a177a4e9/attachment.asc>