Re: Current, official Hg repository?
16 years, 11 months
Rick Rankin
Rick Rankin
> ----- Original Message ----
> From: Stephen J. Turnbull <xxx＠yyy>
> To: Rick Rankin <xxx＠yyy>
> Cc: XEmacs Beta <xxx＠yyy>
> Sent: Friday, February 1, 2008 6:09:58 PM
> Subject: Re: Current, official Hg repository?
>
> Rick Rankin writes:
>
> > I'm seeing the same thing. 'hg pull' gives me
> >
> > $ hg pull
> > abort: repository default not found!
>
> No, that's not the same thing. Vladimir at least was able to connect
> to the repository.
Well, by 'same thing', I meant that 'hg tip' gives me the same information that Vladimir was reporting:
changeset: 4310:a6d7e031a10b
tag: tip
user: Mike Sperber <sperber(a)deinprogramm.de>
date: Thu Dec 06 20:10:16 2007 +0100
summary: Fix two Tailor glitches.
>
> What does `grep default .hg/hgrc' tell you?
Actually, there's no hgrc file in the .hg directory. The contents are
$ ls -al .hg
drwxr-xr-x+ 3 rick Users 0 Feb 1 16:10 .
drwxr-xr-x+ 16 rick Users 0 Feb 1 16:10 ..
-rw-r--r-- 1 rick Users 57 Dec 7 17:05 00changelog.i
-rw-r--r-- 1 rick Users 8 Feb 1 16:10 branch
-rw-r--r-- 1 rick Users 95 Dec 7 17:08 branch.cache
-rw-r--r-- 1 rick Users 68085 Feb 1 16:10 dirstate
-rw-r--r-- 1 rick Users 15 Dec 7 17:05 requires
drwxr-xr-x+ 3 rick Users 0 Feb 1 14:52 store
-rw-r--r-- 1 rick Users 0 Dec 7 17:05 undo.dirstate
This is on Cygwin; however, my Linux box has exactly the same contents and gives exactly the same message to 'hg pull'. Perhaps I did the wrong thing when I first got the source. I'm pretty sure I ran
hg clone http://hg.debian.org/hg/xemacs/xemacs-beta
when I first got the source. Maybe I need to start over?
> If it's
> ssh://hg.debian.org//hg/xemacs/xemacs-beta, then you probably are
> having problems with your ssh-agent (need to ssh-add, maybe?)
> Otherwise, if something other than
> http://hg.debian.org/hg/xemacs/xemacs-beta is returned, you can try
> setting it to that. This may not work (eg, if your original repo was
> cloned from one of our experimental repos or if it's a CVS workspace
> ;-), in which case you'll have to do a new
>
> hg clone http://hg.debian.org/hg/xemacs/xemacs-beta
>
> Note that Mercurial's default behavior is somewhat inconvenient for
> non-core-developers. You can get "cvs update" behavior with "hg pull -u"
> which automatically follows up an "hg pull" with an "hg update". I
> don't know if there's a cvsrc-like way to make "-u" the default option
> for pull.
>
> You can also enable the fetch extension by adding
>
> [extensions]
> hgext.fetch =
>
> to ~/.hgrc. This performs an hg pull then an hg update, followed by
> calling your favorite 3-way merge program for any files that have
> conflicts.
>
Scratch that. I was looking through some of the Mercurial-related messages that I've saved, and I found one from Michael Sperber on 12/7 (see http://calypso.tux.org/pipermail/xemacs-beta/2007-December/012893.html) that gives the following commands for initially getting the source:
hg init xemacs
cd xemacs
hg pull http://hg.debian.org/hg/xemacs/xemacs-beta
*That's* how I initially got the source. It looks like I should have used 'hg clone' instead?
--Rick
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 2 participants
- 2 comments
Converting from using CVS to hg
16 years, 11 months
robert delius royar
robert delius royar
I have 21.5.b28 from CVS which I have kept uptodate. I also have a few
changes to files in src and lisp for my own use.
I just got a clone of the current tree using
mv xemacs xemacs-cvs
hg clone http://hg.debian.org/hg/xemacs/xemacs
When I want to update the xemacs tree, do I
cd xemacs
hg pull http://hg.debian.org/hg/xemacs/xemacs
If I move over my changed files from xemacs-cvs, will hg merge new
changes instead of replacing the files? CVS merged the changes.
If I am only compiling and using XEmacs--not contributing code, is hg
still the way I should go? I know that the CVS archive is still
being updated at some points.
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 3 participants
- 3 comments
21.5-b28 strange behaviour: buffer modification flag set, even though I can't remember having changed anything
16 years, 11 months
Thomas Mittelstädt
Thomas Mittelstädt
Hallo,
This happens sometimes, especially with (generated) Makefiles. When I
try undo, xemacs tells me that there is no undo information.
When I reload the buffer, I can't see any visible changes.
What could that be?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 2 participants
- 6 comments
Re: Current, official Hg repository?
16 years, 11 months
Rick Rankin
Rick Rankin
>
> ----- Original Message ----
> From: Jerry James <xxx＠yyy>
> To: Vladimir G. Ivanovic <xxx＠yyy>
> Cc: XEmacs Beta <xxx＠yyy>
> Sent: Friday, February 1, 2008 12:38:03 PM
> Subject: Re: Current, official Hg repository?
>
> Hi Vladimir,
>
> 2008/2/1 Vladimir G. Ivanovic <xxx＠yyy>:
> > Is
> >
> > http://hg.debian.org/hg/xemacs/xemacs-beta
> >
> > still the official Mercurial XEmacs source repository? If so, is it
> > correct that the last update to it was:
> >
> > # hg tip
> > changeset: 4310:a6d7e031a10b
> > tag: tip
> > user: Mike Sperber <xxx＠yyy>
> > date: Thu Dec 06 20:10:16 2007 +0100
> > summary: Fix two Tailor glitches.
> > ?
> >
>
> That is the correct repository, yes. However, that is not the last
> update. The last one is this:
>
> changeset: 4405:4b62544f5139
> tag: tip
> user: Vin Shelton <xxx＠yyy>
> date: Fri Jan 18 22:06:01 2008 -0500
> summary: Use debug version of Intel's math library when debugging.
>
> If you run "hg pull" does it tell you about more changesets? If not,
> then does "hg update" say it has applied already pulled changesets?
I'm seeing the same thing. 'hg pull' gives me
$ hg pull
abort: repository default not found!
and 'hg update' says
$ hg -v update
resolving manifests
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
--Rick
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
event-Xt.c question
16 years, 11 months
Jerry James
Jerry James
I'm going to try to clean up the stuff valgrind is complaining about.
The leakage stuff will take a little time, it looks like, so I'm going
for the low-hanging fruit first. As XEmacs runs, valgrind complains
bitterly about lots and lots of cases where we essentially memcpy(&x,
&x, sizeof(x)). Since memcpy() is only guaranteed to work on
nonoverlapping addresses, a conforming memcpy implementation *could*
scramble the bytes of x. It turns out these memcpy()s are gcc's
doing. For structs x and y, "x = y;" gets turned into a memcpy call,
without first checking that &x != &y. That should probably be
considered a gcc bug, but on the other hand, there's no need for us to
do "x = x;" either.
So here's the first case I hit. In event-Xt.c, function
emacs_Xt_event_handler, line 1460 says:
x_event_copy = &EVENT_MAGIC_X_EVENT (emacs_event);
which the preprocessor expands to:
x_event_copy = &((emacs_event)->event.magic.underlying.x_event);
Next a bunch of stuff happens in a switch statement, followed on line 1496 by:
SET_EVENT_MAGIC_X_EVENT (emacs_event, *x_event_copy);
which the preprocessor expands to:
do { (emacs_event)->event.magic.underlying.x_event = (*x_event_copy);
} while (0);
There is no code in between that changes the value of the pointers
emacs_event or x_event_copy, so this amounts to:
x = &y;
y = *x;
As far as I can see, the SET_EVENT_MAGIC_X_EVENT call is a no-op. I'd
like to remove it. Any objections?
--
Jerry James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments