all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ralf Angeli <angeli@caeruleus.net>
Cc: Richard Stallman <rms@gnu.org>,
	auctex-devel@gnu.org, emacs-devel@gnu.org,
	monnier@iro.umontreal.ca, Eli Zaretskii <eliz@gnu.org>
Subject: Re: CVS repository synchronization for RefTeX
Date: Mon, 01 Jan 2007 00:57:08 +0100	[thread overview]
Message-ID: <87fyav1uwb.fsf@neutrino.caeruleus.net> (raw)
In-Reply-To: <20061231222721.GA1424@kobe.laptop> (Giorgos Keramidas's message of "Mon\, 1 Jan 2007 00\:27\:22 +0200")

* Giorgos Keramidas (2006-12-31) writes:

>     Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>     There are many people who use RefTeX but still use Emacs 21,
>     and even after the 22 release, this will be true for quite a
>     while.
>
> This may require branching *inside* the Emacs CVS tree, i.e. to
> create an `emacs-21' maintenance branch,

We are not talking about maintenance, but about regular development
which involves new features.  RefTeX is supposed to progress and stay
compatible with Emacs 21 and XEmacs at the same time.

>     David Kastrup <dak@gnu.org> wrote:
>
>     RefTeX is released standalone (unsynchronized with Emacs
>     releases), and creating its tarballs and stuff requires
>     Makefiles and similar that are not present in the Emacs tree.
>
> This is an artifact of the fact that RefTeX is maintained
> separately from Emacs.  It it was maintained as part of the same
> integrated source tree, then RefTeX could use the Emacs build
> process for these things, right?

No, because it would not be possible to install a new standalone
version of RefTeX.

> Right.  There are two different issues here, and I'm not sure if
> they can both be solved in the `right' way:
>
>     * Maintaining RefTeX outside of Emacs means that there is going to
>       be integration effort every time a new `source-drop' of RefTeX has
>       to be merged into the Emacs source tree.  We also lose any sort of
>       fine-grained file history we would have if the commits were done
>       directly in the CVS tree of Emacs.

I don't see a big benefit in having the history directly in Emacs.  If
you are interested in it, you can get it from the separate repository.

>     * Maintaining RefTeX as part of the Emacs source tree reduces
>       integration effort, and lets us keep a better log of RefTeX
>       changes in the CVS tree of Emacs.  It also means that RefTeX for
>       other Emacsen has to be maintained in *their* source tree though,

Again, there is one RefTeX and that is supposed to work with different
Emacs and XEmacs versions.

>       and risks a `fork' between the various RefTeX integration efforts
>       for all the different GNU Emacs versions and the other Emacsen.
>
> I'm not sure if there is a good way to solve both problems.
>
>     Ralf Angeli <angeli@caeruleus.net> wrote:
>
>     If the part is maintained in a separate repository it is possible to
>     check code into Emacs' repository when it is in releasable state,
>     e.g. when a separate release of the part is being made.  Then one can
>     go on developing in the separate repository without endangering Emacs'
>     state as a whole.
>
> But this means that it is non-trivial to keep a history of the merges,

You'll have the history in Emacs' CVS repository.  With an entry every
time a release of RefTeX is checked into the Emacs repository.

> and resync the official source tree of GNU Emacs with the disconnected,
> official tree of RefTeX.

That depends if changes to RefTeX files in the Emacs repository are
allowed, which I would be in favor of.  In that case we'd need some
way of transferring changes made in the Emacs repository into the
RefTeX repository; preferrably automatically.  That's what the subject
of this message refers to.

> The people who currently maintain cc-mode and Gnus may have useful
> feedback, regarding the tools they use for the job.  Do you think it's a
> good idea to ask them and see what they have to say about the best way
> to merge RefTeX source-drops with the CVS tree of Emacs and keep merging
> updates, as they are committed to a separate RefTeX repository?

Well, I was hoping for some of them to chip into this thread.

-- 
Ralf

  reply	other threads:[~2006-12-31 23:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-28 22:53 CVS repository synchronization for RefTeX Ralf Angeli
2006-12-29 22:04 ` Stefan Monnier
2006-12-29 23:43   ` Ralf Angeli
2006-12-30 14:20     ` Eli Zaretskii
2006-12-30 15:08       ` Ralf Angeli
2006-12-30 15:20         ` Eli Zaretskii
2006-12-30 16:01           ` Ralf Angeli
2006-12-30 16:47           ` Carsten Dominik
2006-12-30 18:03             ` Eli Zaretskii
2006-12-30 18:50               ` Ralf Angeli
2006-12-30 19:03                 ` Eli Zaretskii
2006-12-30 19:18                   ` Ralf Angeli
2006-12-31  1:46                   ` Richard Stallman
2006-12-30 21:28               ` Alan Shutko
2006-12-30 21:55               ` Reiner Steib
2006-12-31 22:27               ` Giorgos Keramidas
2006-12-31 23:57                 ` Ralf Angeli [this message]
2007-01-01  7:09                   ` Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX) Michael Olson
2007-01-01 15:21                     ` Ways of keeping Emacs 22 and external projects in sync Ralf Angeli
2007-01-01 17:59                       ` Reiner Steib
2007-01-01 18:36                       ` Giorgos Keramidas
2007-01-03 10:43                       ` Yavor Doganov
2007-01-03 18:32                         ` Michael Olson
2007-01-03 18:29                       ` Michael Olson
2007-01-03 19:53                         ` Ralf Angeli
2007-01-03 22:37                         ` Michael Olson
2007-01-01 18:20                     ` Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX) Giorgos Keramidas
2007-01-01 21:56                 ` CVS repository synchronization for RefTeX Richard Stallman
2006-12-30 18:23     ` Richard Stallman
2006-12-30 18:39       ` Ralf Angeli
2006-12-31  1:47         ` Richard Stallman
2007-01-01 16:01           ` David Kastrup
2007-01-02  3:09             ` Richard Stallman
2007-01-02  7:43               ` David Kastrup
2007-01-02 21:24                 ` Richard Stallman
2007-01-03  8:48                   ` David Kastrup
2007-01-04  2:31                     ` Richard Stallman
2007-01-04 21:51                       ` David Kastrup
2007-01-06  2:54                         ` Richard Stallman
2007-01-06  9:14                           ` David Kastrup
2006-12-30 21:54     ` Reiner Steib
2006-12-31 19:36       ` Ralf Angeli
2007-01-01 17:59         ` Reiner Steib
2007-01-01 19:12           ` Ralf Angeli
2006-12-30 22:07     ` Stefan Monnier
2006-12-29 22:59 ` Richard Stallman
2006-12-30 17:00   ` David Kastrup
2007-01-07 21:42 ` Bill Wohler
2007-01-08 19:25   ` [AUCTeX-devel] " Ralf Angeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fyav1uwb.fsf@neutrino.caeruleus.net \
    --to=angeli@caeruleus.net \
    --cc=auctex-devel@gnu.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.