OpenJDK (Java) migrating from Mercurial?

[Uwe Brauer]

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


   > 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.

To start with, what precisely are your needs? 

What is for you a «short lived branch» (say one with less than 10
changesets)?

Do you need them to be in the general repository? Or can they stay in
the local repository of each contributor and then are rebased, the way I
described?

If you want that even short lived branches are in the central
repository, I still would consider to use named branches over bookmarks.

I have three problems with bookmarks

    1. I barely can see which changeset belongs to which branch

    2. If I create a bookmark I don't create a head (and I don't like
       fast-forwarding, (see my other mail)). I prefer git's manner to
       merge two branches even with a linear history, you can either do
       a fast-forward or a «regular» merge, in mercurial you can't.

    3. How do you avoid name conflicting with bookmarks? Maybe one could
       circumvent these conflict using the remotebookmark extension, but
       this extension confuses me even more.


   > 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?

All the repositories which use mercurial and which I know of, have very
few named branches, Xemacs, mercurial itself for example. The
documentation talks about that hundred or more named branches would
cause a problem concerning performance, but I have not seen any deep
quantitative analysis about this issue.



   > Should they use bookmarks?  Topics?  

If you have a non publishing repository, then indeed topics are a very
good compromise. 

   > 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.

I'd really low to see a details analysis of this issue.  
If you have really a lot of short lived branches and want them in the
central repository,  topics seems to me an good alternative, but maybe
someone from the core developers could clarify this question.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5025 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191118/f0b4fd4f/attachment.p7s>