OpenJDK (Java) migrating from Mercurial?

[Malcolm Matalka]

Uwe Brauer <oub at mat.ucm.es> writes:

>    > Craig Ozancin <c.ozancin at gmail.com> writes:
>
>
>    > I think this is also a problem, though.  As someone who is a big hg fan
>    > only recently, I struggled for awhile to figure out how to do branching
>    > in hg and I probably still don't do it very well.  I, almost
>    > exclusively, use bookmarks.  And because there are so many options out
>    > there, there is also no definitive "here is how to do it" document.  The
>    > technical information is also conflicting.  Are hg branches too
>    > expensive for git-like branching?  Some say yes, some say no.  And
>    > topics?  Those don't seem super well documented so I don't even know how
>    > to use them.
>
>    > I think hg is a superior product overall, but I think the branching
>    > situation is not a point of strength.
>
> I strongly disagree.
> The git branching model might be flexible but I don't understand the
> graph with git branches, that is I don't understand which changeset
> belongs to which branch for changeset which are committed some time
> ago.

I understand this is valuable to you.  But I think this is an example of
the problem I stated: I have no idea how to evaluate if your flow is a
good idea or not.  There is nothing conclusion I've found on the
internet or talking to people.

If I'm the CTO of an engineering team of 100 devs banging away at a
monorepo, are named branches too heavy for them for shortlived changes?
Should they use bookmarks?  Topics?  Am I setting myself up for spending
a ton of person-power in a year trying to get a sluggish repo to work?
Using hg would already be considered weird, do I want to deal with the
CEO getting upset at me because devs can't make changes because they
spend 5 minutes doing an hg up?  git has weaknesses but they are pretty
well documented and since there is only one type of branch, the
community knowledge exists to deal with it (even if the solution is not
ideal, everyone is in the same boat).

If I were that CTO, I would tell everyone to just use bookmarks.  They
have weaknesses but at least I feel confident I'm not setting myself up
for pain in a year or two.

Again, I think hg is superior and I use it everywhere unless I have no
choice, but I can also understand, and think it reasonable, when
decisions makers are fearful of using it because an extremely common
task, like branching, doesn't have a concrete, undisputed, "this is how
you do it" answer.  The question in git-land is what you name them,
what's the workflow look like, but how to make a branch is crystal
clear.

>
> With named branches this is different, I always know which changeset is
> in which branch.
>
> I use named branches for long lived branches, but I also use them for a
> short fix, relying on the evolve extension.
>
> Here is what I do.
>
>  hg branch shortfix
>  hack, commit, hack, commit
>  hg up default
>  hg rebase -d . -b shortfix --collapse
>
>
> The branch is still there but hidden.
>
>  hg log -G --hidden
>
> Shows me the hidden named branch. The good point is that I can again use
> the term shortfix in a different situation and there is no conflict with
> the hidden branch. Works like charm.
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
-------------- 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/20191118/45581f54/attachment.asc>