- #TORTOISEHG WORKBENCH MERGING TAKING LONG TIME UPDATE#
- #TORTOISEHG WORKBENCH MERGING TAKING LONG TIME PATCH#
Changes tend to be small, and (again) do not affect baseline repository. > the effort needed to resolve conflicts, if any)Ĭorollary: Patches can be reordered relative to each other, and split or merged. > without any commitment to to keeping the result (other than > flexibility - can include/exclude various changes as needed, Not sure if this is truly a simplification, but it seems so to me. There are rebase events which cause changes to patches, but there are no merge nodes in the baseline repository.
#TORTOISEHG WORKBENCH MERGING TAKING LONG TIME PATCH#
> release repository (e.g., jdk9/jdk9/hotspot), if that'sĬorollary of separation: No direct interaction between patch history and baseline history. > lifetime-until the point it is ready to include in a jdk > separation - each patch remains a separate unit for its entire > worked directly with the mlvm flat patch file model, but have talked > Let me list the pros & cons as I see them. If there is a HG branch model that works better than (versioned) flat patch files, let's use it. This gives maximum flexibility, but may be too unfriendly for us. > Before we jump in, though, I have one big worry, and it's the same as yours, Tom: Which practice of branching will work for us? I have enjoyed using the simplest possible version: Flat patch files, handled with MQ (hg qpush etc.) and manually rebased. My biggest question about branches is, do they work in practice, for the workflows we are intending? (I.e., small scale, provisional & experimental changes, independent workers, controlled mini-integrations.) I don't know anyone who has used them, so I'm slightly doubtful. > second (allowing named branches) will require a modest change to > jcheck, and just needs to be enabled for the sumatra repos. > The first (lax checking of changeset comments) is already present in
> John Coomes is looking into configuring these repos with suitable "jcheck" options to relax some of the OpenJDK rules on changeset structure, and to allow B. (initially empty workbench shelf, for sharing artifacts other than JDK source changes) I suppose part of the problem is that the admin has to create a blacklist of obsolete versions (hashes) which the repo will refuse to accept from out-of-date users.
It also requires an admin's help to do that > away their old repo, clone the rewritten one and then reapply their > rewriting is very inconvenient in shared repos, as everyone must throw For this reason, if two people are working on one mlvm patch, we split the patch into parts, and merge it back up later when the concurrent development is finished.
#TORTOISEHG WORKBENCH MERGING TAKING LONG TIME UPDATE#
The place where you pay for this separation is if two people try to update the same patch, then you have to merge diffs-of-diffs. The effect on repo history is confined to the patch repository, and to the particular patch file that required a rebase. You just generate a new patch (or patches). One advantage of the flat patch file model (as you point out below) is that rebasing a patch set does not require destruction of history. I take it as a given that Mercurial history has to be monotonically increasing within any given repo. > done by the mercurial rebase extension. > By "rebase", I assume you are *not* referring to the history rewriting (bundle of independent branches, occasionally rebased on A) > In concrete terms, we think this comes to something like the following repositories: On Dec 10, 2012, at 5:47 PM, John Coomes wrote:
Subject: Re: Setting up the Mercurial Repositories for Sumatra Mostly the branches stand alone and we haven't had the case where changes have to be merged from multiple named branches.įrom: John Rose Ĭc: Deneau, Tom sumatra-dev at * or after the experiment is deemed one that will not go forward. * after it's been merged in the hotspot main repo * keep the named branch open for changes based on webrev reviews until the webrev is actually accepted, we never actually merge the branch into default in our repo, that happens in the hotspot main repo. * merge the branch with default whenever we deem necessary Messages sorted by: Īt AMD, we have used name branches successfully in our own Hotspot repository clones but we haven't had to face some of the more complicated scenarios outlined below.Next message: Setting up the Mercurial Repositories for Sumatra.Previous message: Setting up the Mercurial Repositories for Sumatra.Setting up the Mercurial Repositories for Sumatra Deneau, Tom tom.deneau at amd.com Setting up the Mercurial Repositories for Sumatra
0 kommentar(er)
