Re: Committer workflow
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> What we should have done, I think, is to use a DAG-oriented VCS,
Do you mean "use the VCS in a non-DAG-oriented manner"? 'Cause
Mercurial is a DAG-oriented VCS, and we're using it in a DAG-oriented
way.
By which you mean committers can pretend their line of development is
a straight line, and not worry about nodes, right?
It doesn't work so well for reviewers, though.
What you describe, if I understand correctly, would create a
linear patch history.
Yes. That's the right thing to do for the reviewers, especially given
how strongly array-oriented Mercurial's UI is. (Hint: show how to
retrieve the hash ID of the parent of a non-merge commit.)
We could do the exact same thing as "git rebase" with MQ,
but it
has the problem (that it shares with "git rebase") that it doesn't
preserve patch identity.
By "preserve patch identity" you mean that the developer can work in a
single workspace, push his patch, and when he later pulls from the
public repo, not get a conflict. Right?
That's a nice property, I agree. But with a UI that made handling
named branches convenient, this wouldn't be a problem. You just drop
the branch on the floor after you push its content, and pull that
right back in with your next update.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches