moving non publishing changesets between secret and draft phases and back to secret
Anton Shestakov
av6 at dwimlabs.net
Wed Aug 9 17:31:37 UTC 2023
09.08.2023 05:39, Mitchell Elutovich пишет:
> However for my co-worker, I'm not sure he would let the addition of
> auto-publish=abort (or he would perhaps just always use --publish and
> defeat the purpose); for his dev repo if I push the changesets (secret
> -> draft -> push -> secret ), is there something wrong with switching
> them into secret in his dev repo (post the push from my dev repo)
> (perhaps also back to secret in mine as well)?
The idea behind phases is they always move effortlessly to the lower
phase (public is lower than draft is lower than secret). During
exchange, for example, be it pull or push, even if you don't have any
new commits, the phases can still change. With this in mind, there's no
inherent issue moving changesets from draft to secret, it's just every
time you pull or push it's possible to have them turn draft again (quite
likely without you noticing).
For example, you can have the same commit in both repo A and repo B, in
repo A it's secret and in repo B it's draft. If you now push from repo A
to repo B, you will see "no changes found (ignored 1 secret
changesets)", however the commit in question will now become draft in
repo A as well. If you instead pushed from repo B, that would yield the
same phase change in repo A, but without any hints about the presence of
secret commits.
This phase movement is implicit by design. It is, as `hg help phases`
says, to prevent common mistakes when modifying history, i.e. to
safeguard against awkward or dangerous situations in your workflow. You
can forcibly manipulate phases if you know what you're doing, but I'd
suggest considering something less prone to potential errors. In
addition, having changesets live as long as possible in a non-public
phase is the best way to use evolve - after all you shouldn't rewrite
public commits.
If you're using secret phase to simply prevent accidentally pushing
those commits, maybe it'd be better to use a default revset instead. See
`hg help config.paths`, you can set a specific revision for each path
that your repo knows (e.g. main repo or your colleague's). Something
like this:
[paths]
main = https://...
main:pushrev = public()
Having personal development repos set to non-publishing is recommended
even without topics, and much more when using them. Setting auto-publish
to "abort" or "confirm" is also good for everyone who's allowed to
publish changesets in the main repo. And main repo can be set to not
publishing, so that someone can review changes that are supposed to go
to production and then manually publish them. You can probably make this
setup work really well, provided everyone's on board with it.
More information about the Evolve-testers
mailing list