deleting rcs keywords from emacs sources

deleting rcs keywords from emacs sources

[Miles Bader]

A few files in the emacs source have embedded `rcs keywords', which look
like $Id: ... $ and are rewritten by cvs upon checkout/checkin (I'm not
entirely sure which) to automatically reflect 

These are quite annoying when merging between branches because they
cause spurious conflicts (as they contain the revision number, they are
guaranteed to differ between branches), and as far as I know aren't
really particularly useful, so I'd like to simply delete them from the
emacs sources.

Any objections?

-Miles
-- 
97% of everything is grunge

Re: deleting rcs keywords from emacs sources

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 23 Mar 2004 15:46:35 +0900
> 
> These are quite annoying when merging between branches because they
> cause spurious conflicts (as they contain the revision number, they are
> guaranteed to differ between branches), and as far as I know aren't
> really particularly useful, so I'd like to simply delete them from the
> emacs sources.

I, for one, would be very happy when these keywords are removed.

Re: deleting rcs keywords from emacs sources

[Kim F. Storm]

Eli Zaretskii <eliz@elta.co.il> writes:

> > From: Miles Bader <miles@lsi.nec.co.jp>
> > Date: 23 Mar 2004 15:46:35 +0900
> > 
> > These are quite annoying when merging between branches because they
> > cause spurious conflicts (as they contain the revision number, they are
> > guaranteed to differ between branches), and as far as I know aren't
> > really particularly useful, so I'd like to simply delete them from the
> > emacs sources.
> 
> I, for one, would be very happy when these keywords are removed.

Me too!  Id keywords are nothing but trouble!!!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: deleting rcs keywords from emacs sources

[spiegel]

> [...] and as far as I know aren't really particularly useful,
> so I'd like to simply delete them from the
> emacs sources.

I absolutely, positively couldn't live without them. I have in fact doubts whether 
intelligent life on earth would be possible at all without them. Of course 
that could be just me, so I'm open for counter-arguments :-)

I have used these keywords on countless occasions in VC maintenance. I don't 
know how I should identify the file versions that people are talking about 
without these stamps inside the files.  It is true that as long as people 
use vanilla code from an Emacs release, they can always say "I have this 
problem with VC from Emacs 21.x", but it is still easier for me if they 
just say "vc.el version 1.311 barfs on me".  Then I don't have to go looking 
which version we shipped with Emacs 21.x (if a release tag was applied at 
all).

Identifying the version becomes impossible when I send people an updated copy 
of vc.el (which I often do), or they grab it from CVS.
What other means would be available?  Should I ask for an md5sum of the 
file, or a copy of the file itself and diff it against my copy?

If the headers are a problem during merging, I think it would be very worthwhile 
to implement a way for the merge operation to ignore them. That would be 
helpful for many people like myself for whom the version headers are an 
integral part of their work routine. (Incidentally, a user once reported 
a VC bug to me in an old version that didn't have headers in the file, and 
he was astonished that he couldn't find any.)

As I said, I am certainly open for alternatives (incidentally, does your remark 
mean that arch doesn't have version headers at all, Miles)?

Sorry for the rough writeup and the unfamiliar e-mail address, I'm writing from 
a customer site.

Andre

Re: deleting rcs keywords from emacs sources

[Miles Bader]

spiegel@genion.de writes:
> As I said, I am certainly open for alternatives

I'd say that it should usually be the same as any emacs bug report --
M-x emacs-version (if they're actively tracking CVS, they can easily
enough get the cvs revision with `cvs status').

> incidentally, does your remark mean that arch doesn't have version
> headers at all, Miles?

Nope, and won't -- they're a big ball of hair just using CVS, and they'd
be even more insane with arch.  [In the case of arch, of course, there's
a `version' for the source tree as a whole, which could be reported by
M-x emacs-version for development trees.]

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: deleting rcs keywords from emacs sources

[Juanma Barranquero]

On Tue, 23 Mar 2004 09:51:11 +0000 (GMT)
spiegel@genion.de wrote:

> Identifying the version becomes impossible when I send people an updated copy 
> of vc.el (which I often do), or they grab it from CVS.
> What other means would be available?  Should I ask for an md5sum of the 
> file, or a copy of the file itself and diff it against my copy?

Now, if we switched from CVS to Subversion, we could have our cake and
eat it too (in Subversion, keywords don't cause spurious
conflicts/differences).

Of course that's not the best or only good feature of Subversion.
Maintaining history when a file gets moved (as recently done on many
lisp/ packages) comes to mind. And lots of other goodies: directory
versioning, good performance on acces to remote repositories (CVS is a
dog, as I'm forced to remember every time I commit a lisp/ChangeLog
change), versioned metadata, etc.

I know there are Emacs maintainers whose preferred VC tool is arch, and
I've only heard good things about it, but it suffers at least two
problems, IMHO of course: there is no arch port to Windows, and the
decentralized model arch supports, though interesting, is quite
different from the one in CVS, while Subversion is modelled to be "a
better CVS". Switching to Subversion would be, I think, a lot less
painful.

Yeah, this is an off-side plea to at least consider the idea of
switching to SVN. The Apache people is carefully doing it, one repo at a
time, and it seems like the experience is being very positive.

OTOH, Karl Fogel is an Emacs developer and I suppose he's reading the
list, so he could make the point far, far better than me ;-)

                                                                Juanma

Re: deleting rcs keywords from emacs sources

[Miles Bader]

On Tue, Mar 23, 2004 at 12:41:31PM +0100, Juanma Barranquero wrote:
> Now, if we switched from CVS to Subversion, we could have our cake and
> eat it too (in Subversion, keywords don't cause spurious
> conflicts/differences).

Keywords are just a generally stupid idea, so that's hardly an advantage
(even more so in a system with tree-wide version numbers, like subversion --
there the right thing to is just put the version number hacks in your
Makefile).

> I know there are Emacs maintainers whose preferred VC tool is arch, and
> I've only heard good things about it, but it suffers at least two
> problems, IMHO of course: there is no arch port to Windows

I don't use windows so it's hard for me to judge, but I believe there are
several ports of tla to windows, it's just that none of them is free from
dependencies on particular non-standard environment (cygwin or various
microsoft environments, etc).

> and the decentralized model arch supports, though interesting, is quite
> different from the one in CVS

Yes -- it's much, much (much) better than CVS (and subversion).  This is
_not_ an advantage of subversion.

> while Subversion is modelled to be "a better CVS". Switching to Subversion
> would be, I think, a lot less painful.

Actually I suspect that arch would is likely easier, despite the differences
-- its network model is extremely flexible and simple, and it has none of the
special hosting requirements that subversion does.

I say "is" because as you might know, there's _already_ an emacs arch archive
(synchronized with CVS), which could take over from CVS quickly if the
developers wanted that (the main sticking point being that it's running on
fencepost, not on savannah, so anyone that wanted commit access would need to
have ssh access there; moving to savannah would probably be pretty
straightforward except that _everything_ involving savannah is slow :-)

> Yeah, this is an off-side plea to at least consider the idea of
> switching to SVN. The Apache people is carefully doing it, one repo at a
> time, and it seems like the experience is being very positive.

You might want to check the emacs-devel archives: there was a big thread on
this about 10 months ago -- and at that time I was tentatively on the
subversion, for many of the reasons you gave above.  Now that I've seen
personally how superior arch is, I'm firmly in the arch camp.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: deleting rcs keywords from emacs sources

[Juanma Barranquero]

On Tue, 23 Mar 2004 08:13:16 -0500
Miles Bader <miles@gnu.org> wrote:

> Keywords are just a generally stupid idea, so that's hardly an advantage

Well, no. Keywords are wrong, perhaps, the way they're implemented in
CVS; but is a fact that lots of people find them useful, so dismissing
them as stupid is not very useful, I think. And I'm not defending my
turf here: I don't like keywords and I've never used them.

But quite recently there was a thread on the Subversion list about $log$
(which Subversion *does not* implement), because a guy explained how
they used it to track sources and releases, etc. They had a complex
system, which worked fine for them all allowed them to do *exactly*
what they wanted, and it depended heavily on $log$. Granted: there are
other ways of doing the same things; but that does not mean they aren't
useful, or perhaps *the* right answer to some problems, even.

> I don't use windows so it's hard for me to judge, but I believe there are
> several ports of tla to windows, it's just that none of them is free from
> dependencies on particular non-standard environment (cygwin or various
> microsoft environments, etc).

AFAICS, there is no official Windows port. The existence of home-brewed
ports eases the problem, but doesn't solve it. I could, after all,
compile my own tla; but I'm interested in hacking Emacs, not arch, so I
don't see why should I be forced to do that. What I mean is: before
considering whether to switch to another VC, wide disponibility of the
tool (not in number of platforms, but in number of potential developers
able to use it) should be considered paramount. Perhaps I'm biased
because I'm on Windows :)

> Yes -- it's much, much (much) better than CVS (and subversion).  This is
> _not_ an advantage of subversion.

Sorry, but "much better" is subjective. I know, at least a bit, what
decentralized VC systems (like BitKeeper and Arch and Monotone) do, and
I agree that it *is* interesting and useful; but I don't think I can
unconditionally agree that it is "better" than the centralized model of
CVS and Subversion and other tools. Decentralized seems to work for
Linux, partly because there is a "centralized repository", known to the
world as Linus Torvalds (I know I'm simplifying there). But a
centralized model is good for quite a lot of environments, and most free
and open-source projects have been developed that way for thirty years.
That's why I mentioned Apache: they're high-profile, and they don't seem
afraid of going to Subversion, so clearly there's not much they find
lacking on it.

(And BTW, speaking of decentralized, there's svk: a BitKeeper-style VC
system built on top of Subversion.)

> Actually I suspect that arch would is likely easier, despite the differences
> -- its network model is extremely flexible and simple, and it has none of the
> special hosting requirements that subversion does.

Subversion requires Berkeley DB 4.0.X or 4.2.X, and, *if* used as an
Apache module, httpd 2.0.48+; having Python is a plus, but not necessary.
Not much more, I think. With respect to ease of porting, you convert the
repository with cvs2svn.py (preserving all history, tags, branches, etc),
install the Apache module, define the access model, and that's all.

> I say "is" because as you might know, there's _already_ an emacs arch archive
> (synchronized with CVS), which could take over from CVS quickly if the
> developers wanted that

Yes, I know. But I'm not letting the fact that there's already an
alternative trick me into believing this is necessarily the best one :)

> You might want to check the emacs-devel archives: there was a big thread on
> this about 10 months ago -- and at that time I was tentatively on the
> subversion, for many of the reasons you gave above.  Now that I've seen
> personally how superior arch is, I'm firmly in the arch camp.

Well, I'm in no camp, other than the non-CVS one. I firmly believe
switching to another, better VC would be a good move for Emacs; and I
also think that doing it to Subversion would be easier and safer (in the
sense that Subversion seems a stable, well-maintained and active
project: my admittedly subjective view of arch is that of a on-and-off
development effort with very few contributors).

All that said, if Emacs switched to arch and I had good, up-to-date
tools to access it from Windows I wouldn't complain. But still think
Subversion is a better match to our needs.

                                                                Juanma

Re: deleting rcs keywords from emacs sources

[Miles Bader]

On Tue, Mar 23, 2004 at 03:01:59PM +0100, Juanma Barranquero wrote:
> > Yes -- it's much, much (much) better than CVS (and subversion).  This is
> > _not_ an advantage of subversion.
> 
> Sorry, but "much better" is subjective. I know, at least a bit, what
> decentralized VC systems (like BitKeeper and Arch and Monotone) do, and
> I agree that it *is* interesting and useful; but I don't think I can
> unconditionally agree that it is "better" than the centralized model of
> CVS and Subversion and other tools.

I think the main point is that `centralized' is the easy case, and arch can
do that too.  If people want centralized, that's no problem -- but the
additional freedom of painless distributed development is a _significant_
advantage to arch.

[Perhaps this is not something that's entirely obvious if you've not used it
before, but it's wonderfully liberating.]

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: deleting rcs keywords from emacs sources

[Juanma Barranquero]

On Tue, 23 Mar 2004 09:35:20 -0500
Miles Bader <miles@gnu.org> wrote:

> I think the main point is that `centralized' is the easy case, and arch can
> do that too. If people want centralized, that's no problem -- but the
> additional freedom of painless distributed development is a _significant_
> advantage to arch.

Yeah, I understand that. My point, OTOH, is that Emacs developers
probably don't want or need an additional freedom they're not going to
use, if the cost is a less stable, less well maintained or more complex
tool.

Of course, I'm not trying to speak on behalf of the Emacs developers
here, it's just a feeling. But, as the issue of enhancement value vs.
ease of maintaining is weighted once and again with respect to new
features and functionality, the same parameters can be applied to the
choosing of a VC tool. I'm *sure* there are lots of projects for which
arch is the right (or best) tool, much better than Subversion. I simply
don't see why should it be the case for Emacs.

> [Perhaps this is not something that's entirely obvious if you've not used it
> before, but it's wonderfully liberating.]

I can well imagine it, and I'm looking forward to giving a fair try to arch,
when it is well supported on Windows and for the right projects.

                                                                Juanma

Re: deleting rcs keywords from emacs sources

[Stefan Monnier]

Can we either stick to the subject (i.e. removing $Id$) or at least change
the subject line, please?


        Stefan


>>>>> "Juanma" == Juanma Barranquero <jmbarranquero@wke.es> writes:

> On Tue, 23 Mar 2004 09:35:20 -0500
> Miles Bader <miles@gnu.org> wrote:

>> I think the main point is that `centralized' is the easy case, and arch can
>> do that too. If people want centralized, that's no problem -- but the
>> additional freedom of painless distributed development is a _significant_
>> advantage to arch.

> Yeah, I understand that. My point, OTOH, is that Emacs developers
> probably don't want or need an additional freedom they're not going to
> use, if the cost is a less stable, less well maintained or more complex
> tool.

> Of course, I'm not trying to speak on behalf of the Emacs developers
> here, it's just a feeling. But, as the issue of enhancement value vs.
> ease of maintaining is weighted once and again with respect to new
> features and functionality, the same parameters can be applied to the
> choosing of a VC tool. I'm *sure* there are lots of projects for which
> arch is the right (or best) tool, much better than Subversion. I simply
> don't see why should it be the case for Emacs.

>> [Perhaps this is not something that's entirely obvious if you've not used it
>> before, but it's wonderfully liberating.]

> I can well imagine it, and I'm looking forward to giving a fair try to arch,
> when it is well supported on Windows and for the right projects.

>                                                                 Juanma

Re: deleting rcs keywords from emacs sources

[Juanma Barranquero]

On 23 Mar 2004 10:14:57 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Can we either stick to the subject (i.e. removing $Id$) or at least change
> the subject line, please?

No objection to removing keywords.

                                                                Juanma

Re: deleting rcs from emacs sources

[David Kastrup]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> On 23 Mar 2004 10:14:57 -0500
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > Can we either stick to the subject (i.e. removing $Id$) or at
> > least change the subject line, please?
> 
> No objection to removing keywords.

Ok, I removed it from the subject line, but I don't see what this
will buy us.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

We're going to keep using CVS for Emacs for the foreseeable future.
(I don't have time to even consider the merits of anything else.)

Re: deleting rcs keywords from emacs sources

[Stefan Monnier]

>> Keywords are just a generally stupid idea, so that's hardly an advantage
> Well, no. Keywords are wrong, perhaps, the way they're implemented in

Can we stop talking generically and get to the specific of CVS keywords in
the Emacs repository?
The reason why I want them gone is because they make handling branches (as
well as uncommitted local changes, which are basically a kind of
ultra-lightweight branch) more painful than needed, and that's particularly
annoying when you want to make some of the updating automatic.

> AFAICS, there is no official Windows port. The existence of home-brewed

And can we stop talking Arch-vs-Subversion.  There's already plenty of such
threads elswhere.  Emacs is not about to switch to one system or another.

> I agree that it *is* interesting and useful; but I don't think I can
> unconditionally agree that it is "better" than the centralized model of
> CVS and Subversion and other tools. Decentralized seems to work for

All the decentralized models I know of have the centralized model as
a special case.  You can definitely use Arch with a single centralized
server (accessed via SFTP) and it works very much like Subversion or CVS in
this respect.  And I expect that if Emacs ever switches to something like
Arch or Bitkeeper it will be setup in a centralized way anyway, so that part
of the equation is simply out.


        Stefan

Wheter to switch to another VC, and which one...

[Juanma Barranquero]

> And can we stop talking Arch-vs-Subversion.  There's already plenty of such
> threads elswhere.  Emacs is not about to switch to one system or another.

Well, Emacs is not about to switch, but, if we don't talk about it, it will
certainly never switch. Perhaps you feel that's fine. I for sure feel is
*not*.

> All the decentralized models I know of have the centralized model as
> a special case.  You can definitely use Arch with a single centralized
> server (accessed via SFTP) and it works very much like Subversion or CVS in
> this respect.

I know. That doesn't mean there aren't hidden costs in using a more
generic tool for a quite specific use.

> And I expect that if Emacs ever switches to something like
> Arch or Bitkeeper

RMS using BitKeeper, that'd be funny.

                                                                Juanma

Re: Wheter to switch to another VC, and which one...

[Stefan Monnier]

> Well, Emacs is not about to switch, but, if we don't talk about it, it
> will certainly never switch. Perhaps you feel that's fine. I for sure feel
> is *not*.

Emacs has not been at the forefront of technology and I don't see any
reason why this will change.

In any case, I don't see how we'll be able to switch to Arch or to
Subversion before Emacs itself supports those tools as well as it
supports CVS.

> I know. That doesn't mean there aren't hidden costs in using a more
> generic tool for a quite specific use.

Well, there will be downsides to any alternative.  But it is irrelevant to
me whether those downsides are due to "side effects of being able to have
distributed branches" or whether they're due to side effects of "being able
to branch in the same way that you copy" or whether they're due to arbitrary
decisions of the author or anything else.

>> And I expect that if Emacs ever switches to something like
>> Arch or Bitkeeper

> RMS using BitKeeper, that'd be funny.

I felt this thread ws a bit too serious,


        Stefan

Re: Wheter to switch to another VC, and which one...

[Masatake YAMATO]

> > Well, Emacs is not about to switch, but, if we don't talk about it, it
> > will certainly never switch. Perhaps you feel that's fine. I for sure feel
> > is *not*.
> 
> Emacs has not been at the forefront of technology and I don't see any
> reason why this will change.
> 
> In any case, I don't see how we'll be able to switch to Arch or to
> Subversion before Emacs itself supports those tools as well as it
> supports CVS.

Hey, the great pcl-cvs maintainer, did you check psvn.el and xtla.el?

Stefan Reichoer's works are interesting.
- http://xsteve.nit.at/prg/emacs/psvn.el
- http://xsteve.nit.at/prg/emacs/xtla.el

I have special interests in xtla.el.
I have already gotten in touch with the author; and asked to open a
project for xtla.el on savannah.

I will work on M-x xtla-rbrowse when the project is opened.

Masatake YAMATO

Re: Wheter to switch to another VC, and which one...

[Stefan Monnier]

> Hey, the great pcl-cvs maintainer, did you check psvn.el and xtla.el?

Yes but not nearly enough yet.
But more importantly, note the "Emacs itself" in my message: it should be
included in Emacs, not some third party.


        Stefan

Re: Wheter to switch to another VC, and which one...

[Masatake YAMATO]

> > Hey, the great pcl-cvs maintainer, did you check psvn.el and xtla.el?
> 
> Yes but not nearly enough yet.
> But more importantly, note the "Emacs itself" in my message: it should be
> included in Emacs, not some third party.

As far as I know, at the early development stage, pcl-cvs development was not 
part of Emacs development. If psvn.el and xtla.el become good enough, these
could be distributed with Emacs, like cc-mode and gnus.

About xtla.el I will take my time for the above goal.

Masatake YAMATO

Re: Wheter to switch to another VC, and which one...

[Stefan Monnier]

> As far as I know, at the early development stage, pcl-cvs development was
> not  part of Emacs development.  If psvn.el and xtla.el become good
> enough, these could be distributed with Emacs, like cc-mode and gnus.

Indeed.  I very much hope they will.
Just so things are clear: I did not intend to say that they are bad because
they're not invented here, but just that I wouldn't want to switch to
a different system until the convenience of something like PCL-CVS is
available without having to install a separate package.

> About xtla.el I will take my time for the above goal.

Great to hear.


        Stefan

Re: Wheter to switch to another VC, and which one...

[Kim F. Storm]

Juanma Barranquero <jmbarranquero@wke.es> writes:

> > And can we stop talking Arch-vs-Subversion.  There's already plenty of such
> > threads elswhere.  Emacs is not about to switch to one system or another.
> 
> Well, Emacs is not about to switch, but, if we don't talk about it, it will
> certainly never switch. Perhaps you feel that's fine. I for sure feel is
> *not*.

We have discussed moving quite a lot of the lisp files around, and
doing that under Subversion (which keep history across moves) would be
a big win compared to CVS.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Wheter to switch to another VC, and which one...

[Miles Bader]

On Wed, Mar 24, 2004 at 01:17:05AM +0100, Kim F. Storm wrote:
> We have discussed moving quite a lot of the lisp files around, and
> doing that under Subversion (which keep history across moves) would be
> a big win compared to CVS.

Arch too (of course).

If you look at my arch archive of emacs, you can see that already for some
recently renamed files, e.g., when Eli did some renaming to be
msdos-compatible.

-Miles
-- 
We have met the enemy, and he is us.  -- Pogo

Re: Wheter to switch to another VC, and which one...

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Wed, Mar 24, 2004 at 01:17:05AM +0100, Kim F. Storm wrote:
> > We have discussed moving quite a lot of the lisp files around, and
> > doing that under Subversion (which keep history across moves) would be
> > a big win compared to CVS.
> 
> Arch too (of course).
> 
> If you look at my arch archive of emacs, you can see that already for some
> recently renamed files, e.g., when Eli did some renaming to be
> msdos-compatible.

Does it keep the history on the moved/renamed file as well?

Ah, yes, I suppose arch can do that with the arch tag on each file.
Clever!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Wheter to switch to another VC, and which one...

[Miles Bader]

On Wed, Mar 24, 2004 at 11:52:34AM +0100, Kim F. Storm wrote:
> > > We have discussed moving quite a lot of the lisp files around, and
> > > doing that under Subversion (which keep history across moves) would be
> > > a big win compared to CVS.
> > 
> > Arch too (of course).
> 
> Does it keep the history on the moved/renamed file as well?
> 
> Ah, yes, I suppose arch can do that with the arch tag on each file.

The thing to remember is that arch doesn't keep per-file history _at all_ --
log files are associated with changesets.

In many cases, this is actually more useful than a per-file history, but
sometimes you do want to see that.  As it turns out, there's enough
information kept in the changeset logs that you can easily (and
automatically) track a file's evolution through a series of changesets.

I have a shell script (`tla-file-log') that does this and emits cvs-style log
output.  However, in practice I find I rarely use it; more often I just want
to see the overall branch history.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Wheter to switch to another VC, and which one...

[Stefan Monnier]

> We have discussed moving quite a lot of the lisp files around, and
> doing that under Subversion (which keep history across moves) would be
> a big win compared to CVS.

Any new system supports that: Arch, Subversion, darcs, MetaCVS, Monotone,
OpenCM, ...


        Stefan

Re: deleting rcs keywords from emacs sources

[Nick Roberts]

 > > while Subversion is modelled to be "a better CVS". Switching to Subversion
 > > would be, I think, a lot less painful.
 > 
 > Actually I suspect that arch would is likely easier, despite the differences
 > -- its network model is extremely flexible and simple, and it has none of the
 > special hosting requirements that subversion does.
 > 
 > I say "is" because as you might know, there's _already_ an emacs arch archive
 > (synchronized with CVS), which could take over from CVS quickly if the
 > developers wanted that (the main sticking point being that it's running on
 > fencepost, not on savannah, so anyone that wanted commit access would need to
 > have ssh access there; moving to savannah would probably be pretty
 > straightforward except that _everything_ involving savannah is slow :-)

There is a project called Xouvert on Savannah that is trying to use arch for
version control. If you look at their mailing list you'll see that they have
had difficulty because of security issues. It might be a good idea to monitor
their progress (or lack of it).

Nick

Re: deleting rcs keywords from emacs sources

[Nick Roberts]

 > Now, if we switched from CVS to Subversion, we could have our cake and
 > eat it too (in Subversion, keywords don't cause spurious
 > conflicts/differences).

Whatever the advantages of Subversion (or Arch), keywords would not appear
to be one of them because the info manual on CVS says:

info>   If you merge files containing keywords (*note Keyword
info> substitution::), you will normally get numerous conflicts during the
info> merge, because the keywords are expanded differently in the revisions
info> which you are merging.

info>   Therefore, you will often want to specify the `-kk' (*note
info> Substitution modes::) switch to the merge command line.  By
info> substituting just the name of the keyword, not the expanded value of
info> that keyword, this option ensures that the revisions which you are
info> merging will be the same as each other, and avoid spurious conflicts.

eg. cvs update -kk -j mybranch

There is a caution:

info>    There is, however, one major caveat with using `-kk' on merges.
info> Namely, it overrides whatever keyword expansion mode CVS would normally
info> have used.  In particular, this is a problem if the mode had been `-kb'
info> for a binary file.  Therefore, if your repository contains binary
info> files, you will need to deal with the conflicts rather than using `-kk'.

The only binary files that I'm aware of in Emacs CVS are the bitmaps for
the toolbar.

Nick

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

I have never liked RCS keywords, and I would be glad if they were gone.

In all cases, they are present because some Lisp package maintainer
wanted them.  Sometimes I argued against this, and sometimes I did not.
I'd guess some of those maintainers are still active, while some of them
are long gone. 

Re: deleting rcs keywords from emacs sources

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I have never liked RCS keywords, and I would be glad if they were gone.
> 
> In all cases, they are present because some Lisp package maintainer
> wanted them.

Ok, given that there's a rough consensus, I'm going to do what Stefan
suggested:  first remove all those from files where there's obviously no
problem (the maintainer is the FSF, or someone that doesn't object, or
someone that appears to be missing for a long time).

-Miles
-- 
We live, as we dream -- alone....