3:55 p.m.
Michael Sperber writes:
I still don't understand what your problem is.
Mercurial makes it somewhat hard to do what I want to do (work in
branches), makes it easy to make mistakes in that mode, and makes it
hard to produce high S/N log listings and diffs.
(You seem to prefer git, but it has essentially the same underlying
model as Mercurial, AFAICS.)
Sure, and Scheme and Emacs Lisp share an underlying model, too. As
usual the devil's in the details. For example, I think that exposing
unstable revnos to the world is bad UI. The no-argument merge command
is bad UI (at least if both heads are on named branches). The fact
that a branch is not treated as a head if it's a proper ancestor of a
head is unintuitive to me, although I'm not prepared to categorize it
as "bad" yet. The fact that tags are commits is ugly. The fact that
a branch has no existence until you commit to it worries me. I can't
think of a "real" use for it, but when writing the script that I
posted for Mats I realized that an empty branch is useful for
simulating concurrency in a single-user context. So there might be
some odd case where it would be really nice to have such a thing.
> I did merge locally (if you thought about it, you'd realize
that,
> because Mercurial won't push if it creates a head), but unfortunately
> there were only two heads so "hg merge" just worked and then push did
> the wrong thing by creating a branch (in almost five years of working
> with distributed VCSes I've only *wanted* push to create a new remote
> branch once). Worse yet, it was totally silent about it.
Normally Mercurial refuses to create remote branches unless the -f
option is specified. Could you be more specific about what you did?
What is written above is what I can remember or deduce about what I
did. All I can add is that the "bytecomp" branch was transplanted to
the end of the "g++-warnings" branch, that in my repo the most recent
commit to "default" was a proper ancestor (merge parent) of the
"bytecomp" head at the time of the push, and that I would NEVER EVER
specify -f to a push to the "xemacs" repository.
Are you sure that "hg push" knows anything about branches? AIUI in
Mercurial "branch" is an attribute of a commit, and single-valued, it
seems (unlike git, where a branch is implemented as an automatically
updated ref, all branches implicitly go back to a root, and a commit
can be on several branches simultaneously). ISTM that hg push has no
need-to-know about "branch", and that the restriction is against
creating new heads. A branch just goes along for the ride, because a
non-trivial branch will have a head.
So my guess is that because tip happened to be on bytecomp when I
pushed, and it was the only head (default didn't have one), hg push
happily pushed it to the xemacs repo, and reset tip of that repo to be
on my branch (possibly because default was inactive).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:24 p.m.
New subject: Mercurial "r####" numbers are not stable, use commit ids
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> I still don't understand what your problem is.
Mercurial makes it somewhat hard to do what I want to do (work in
branches), makes it easy to make mistakes in that mode, and makes it
hard to produce high S/N log listings and diffs.
I think the problem is *how* you go about working in branches, and I
agree a given mode of operation may be better in Mercurial than in git.
I think when you say "branches" you really mean "named branches", and
I
agree some aspects of them are unintuitive. They certainly don't work
very well when you work locally on a set of patches on a common theme,
to revise and push them later. For that setting, I've found that MQ
works exceedingly well. Have you tried it?
Are you sure that "hg push" knows anything about branches?
It doesn't know anything special about "named branches"---I'm guessing
you created a named branch and pushed without an intervening commit to
the old head. In that case, no new heads get created, and I'm guessing
"hg push" doesn't complain.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:26 p.m.
New subject: Mercurial "r####" numbers are not stable, use commit ids
Michael Sperber writes:
I think the problem is *how* you go about working in branches, and I
Yes. I find that Mercurial is as bad as CVS in terms of making me
want to commit everything I write as quickly as possible to get it out
of my face. What's worse is, it makes it easy to do that.
agree a given mode of operation may be better in Mercurial than in
git.
I think when you say "branches" you really mean "named branches", and
I
agree some aspects of them are unintuitive.
I do mean named branches, something I can stash away for a week or
ten, and have the history there when I can come back to it.
They certainly don't work very well when you work locally on a
set
of patches on a common theme, to revise and push them later. For
that setting, I've found that MQ works exceedingly well. Have you
tried it?
A little. But I don't concentrate on a set of patches on a common
theme over a period of time. I work on a wide variety of things in
response to reports on xemacs-beta, and I fix unrelated bugs as I go
along. I didn't find a comfortable way to use MQ in that setting. In
particular, unlike a branch which has a well-defined history and
terminal state, it just didn't work for me to go away from a queue for
very long because it was hard to figure out where I was. On the other
hand, the ability to manipulate complex configurations of patches
isn't useful to me; I've never actually dealt with a situation where
that would be helpful.
The other problem with Mercurial is that there are all these
extensions, but there's no way to find out what they are! "mq" is
mentioned in man hgrc (but nowhere in hg help), and guessing
"transplant" worked. But I wonder what else there might be out
there....
It doesn't know anything special about "named
branches"---I'm guessing
you created a named branch and pushed without an intervening commit to
the old head. In that case, no new heads get created, and I'm guessing
"hg push" doesn't complain.
Well, that's what happened as best I can guess, and Mercurial issued
no complaints.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:25 a.m.
New subject: Mercurial "r####" numbers are not stable, use commit ids
>>>> "ST" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
ST> I do mean named branches, something I can stash away for a week or
ST> ten, and have the history there when I can come back to it.
AFAIK, named branches were not part of Mercurial's original design.
Rather, instead of creating a new branch, the expectation is that the
user would clone the repo and work in the clone.
ST> In particular, unlike a branch which has a well-defined history and
ST> terminal state, it just didn't work for me to go away from a queue
ST> for very long because it was hard to figure out where I was.
Hmm. My work to get MH-E 8.0.3 to fit into the XEmacs package system
happens in fits and starts, sometimes with multiple months of
non-activity, and I haven't had problems picking up where I left off. I
currently have 20 patches in MQ, including some hacks to deal with
unrelated problems that I ran into while working on MH-E 8.0.3.
Here are some aspects of my workflow that might be helpful:
* I keep a Todo file that sketches out the remaining work for a
project. (And for long-running projects, I often leave notes in it
about work that has already been completed.)
* Each patch includes the corresponding ChangeLog entry/entries. These
usually require manual repair of the patch after synching with the
upstream repo, but it's a trivial merge.
* I try to have a naming system for the patches. For example, patches
to other packages to deal with incompatibilities between MH-E 7 and
MH-E 8 are all named <pkg>-mh-e-8.
* I use -m when creating a new patch with qnew. If you forget to do
that, or you want to change the log text, you can use -m with
qrefresh. So if I want to remember what a particular patch does, I
can either do "hg log -r <patch>" or I can look at the ChangeLog
entries that are in the patch.
I have not tried putting the patches into a repo so that they can be
easily shared.
ST> The other problem with Mercurial is that there are all these
ST> extensions, but there's no way to find out what they are! "mq" is
ST> mentioned in man hgrc (but nowhere in hg help), and guessing
ST> "transplant" worked. But I wonder what else there might be out
ST> there....
http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions
cheers,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5799
days inactive
5802
days old
3 comments
4 participants
participants (4)
-
Michael Sperber -
Mike Kupfer -
Stephen J. Turnbull -
Stephen J. Turnbull