Re: deleting rcs keywords from emacs sources

Re: deleting rcs keywords from emacs sources

[spiegel]

As it looks like I'm the only one who sees any benefit in version headers, 
I certainly won't insist on keeping them in there.

> if they're actively tracking CVS, they can easily
> enough get the cvs revision with `cvs status').

Is that really the only answer?  To find out what version of a file you are 
looking at, you need to be hooked up to the version control system?  I often 
send files back and forth, and frequently I need to decide what version 
I'm looking at, with the file being isolated from its version control history.

I find it completely natural, even essential that a file is stamped with the 
version it contains, the stamp being a part of the actual contents of the 
file.

It should be the job of the version control system to ignore this kind of 
changes for operations where it clearly doesn't make sense.  CVS, as somebody 
pointed out, is capable of this for the headers it produces.

I have occasionally received bug reports about old versions of vc.el which didn't 
have any headers in them.  People were astonished that the version control 
part of emacs didn't contain this essential versioning information itself.

Re: deleting rcs keywords from emacs sources

[Miles Bader]

On Tue, Mar 23, 2004 at 06:46:09PM +0000, spiegel@genion.de wrote:
> > if they're actively tracking CVS, they can easily
> > enough get the cvs revision with `cvs status').
> 
> Is that really the only answer?  To find out what version of a file you are 
> looking at, you need to be hooked up to the version control system?

In general, the version of a single file is not what you want for bug
reports, you want the state of the entire _system_.

There are several reasons for this, e.g. (a) it doesn't rely on the the
bug-reporter knowing what the relevant file is (which they often get wrong,
even if they think they do), and (b) many problems which manifest in a
particular piece of code are actually due to changes outside it, or
interactions between changes in both places.  Really you want bug reports to
come from M-x report-emacs-bug, unless the submitter is very knowledgeable,
as that will make sure to include other info that will tell you the state
more exactly.

If someone is using a packaged distribution of emacs, then it should be set
up to generate a meaningful emacs version number, which will tell you what
snapshot of the source tree it is from.

The only other common case (AFAIK) is that someone is actively tracking emacs
CVS; in this case, you probably _still_ want to know the state of the whole
system for the reasons stated above, but the version reported by M-x
emacs-version is not very useful (it effectively just tells you "CVS sometime
after this release").  However, you also know that in this case both that the
user has CVS info easily available, and is probably more knowledgable than
average (so probably _knows_ they have CVS info available).

So given this, I think we ought to (1) encourage people to use M-x
report-emacs-bug, (2) find a way to make M-x emacs-version give more useful
info for CVS checkouts (easy for arch though).

> I often send files back and forth, and frequently I need to decide what
> version I'm looking at, with the file being isolated from its version
> control history.

Er, if you're making changes outside of CVS than the keyword info isn't
going to be very useful, is it?

> I find it completely natural, even essential that a file is stamped with the 
> version it contains, the stamp being a part of the actual contents of the 
> file.

I've seen others say this too, and I suspect that's a major reason people use
rcs keywords -- it gives them warm fuzzies.

> It should be the job of the version control system to ignore this kind of
> changes for operations where it clearly doesn't make sense.  CVS, as
> somebody pointed out, is capable of this for the headers it produces.

It's too much of a tar pit: it means that the V.C.S. is _changing_ the
contents of the file, which is _dangerous_ (see the CVS documentation for
details); arch uses the much more robust model that what you put in is
exactly what you get out.

These keywords are the sort of thing that may seem like a great idea at
first, but which come back to haunt you later (as we now see :-)

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: deleting rcs keywords from emacs sources

[Andre Spiegel]

On Tue, 2004-03-23 at 22:47, Miles Bader wrote:

> > I often send files back and forth, and frequently I need to decide what
> > version I'm looking at, with the file being isolated from its version
> > control history.
> 
> Er, if you're making changes outside of CVS than the keyword info isn't
> going to be very useful, is it?

This has nothing to do with changes outside CVS.  The scenario usually
goes like this: Somebody reports a bug, I fix it.  The user doesn't have
CVS access, my fix is not readily backported into the version of the
file he has, so I send him the entire current source file.  Later, that
person has another problem, and reports it along with the version number
of the file I sent him.  Without version numbers in the files, this is 
very difficult, if not impossible to keep track of.

Now, *if* changes outside of CVS happen, then the version numbers in the
file at least give you a clear indication what CVS version this file was
based on, and then it's trivial to find out what these changes were,
relative to the corresponding CVS version.  This is very difficult to
find out if you have no idea what CVS version the file was based on.

I could go on and on with scenarios that are not Emacs-related, but
where version numbers also play an important role.  For example, people
sometimes print files on paper to carry into a review meeting.  Files
get deployed to machines with no access to the version control system
etc. etc.

> > I find it completely natural, even essential that a file is stamped with the 
> > version it contains, the stamp being a part of the actual contents of the 
> > file.
> 
> I've seen others say this too, and I suspect that's a major reason people use
> rcs keywords -- it gives them warm fuzzies.

I think the scenarios above show the contrary.

> These keywords are the sort of thing that may seem like a great idea at
> first, but which come back to haunt you later (as we now see :-)

I used to think that the keywords, being a huge benefit for myself, did
not cause any trouble elsewhere.  But if they really do, then the cost
vs. the benefit needs to be weighed of course.  As it appears that
several people are suffering trouble, I won't insist on my objections.

In the general case (i.e. outside Emacs development), I firmly believe
that this needs to be handled properly, because surely, many projects
and shops will insist on having such a feature.  If it takes effort to
reconcile this with merging etc., so be it.  A feature is not bad just
because it is non-trivial to implement.

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

    The user doesn't have
    CVS access, my fix is not readily backported into the version of the
    file he has, so I send him the entire current source file.  Later, that
    person has another problem, and reports it along with the version number
    of the file I sent him.  Without version numbers in the files, this is 
    very difficult, if not impossible to keep track of.

I can follow how this is useful for you.  I would guess that only a
few Lisp file maintainers do this, though.

If you put a date manually into the files when you send an entire
file to someone, it would achieve the same purpose, right?
You'd be doing it manually instead of automatically.

How much extra work would that impose on you?
(It depends on how often you actually do this.)

Re: deleting rcs keywords from emacs sources

[Stefan Monnier]

> If you put a date manually into the files when you send an entire
> file to someone, it would achieve the same purpose, right?
> You'd be doing it manually instead of automatically.

The date can even be put automatically (when Emacs saves the file).
At least that's what timestamp.el is for, AFAIK.


        Stefan

Re: deleting rcs keywords from emacs sources

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The user doesn't have CVS access, my fix is not readily
>     backported into the version of the file he has, so I send him
>     the entire current source file.  Later, that person has another
>     problem, and reports it along with the version number of the
>     file I sent him.  Without version numbers in the files, this is
>     very difficult, if not impossible to keep track of.
> 
> I can follow how this is useful for you.  I would guess that only a
> few Lisp file maintainers do this, though.

FWIW, AUCTeX uses RCS tags to announce the version number used
(either released version or CVS revision and build date) in bug
reports sent by the standard bug reporting commands.  Since we don't
release that often, this information helps quite a lot in tracking
what code base the bug report refers to.

> If you put a date manually into the files when you send an entire
> file to someone, it would achieve the same purpose, right?  You'd be
> doing it manually instead of automatically.

If somebody checks out and compiles my CVS archive, I won't be in the
position of putting dates into his files manually.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

    FWIW, AUCTeX uses RCS tags to announce the version number used

AUCTeX is not included in Emacs anyway, so the present issue doesn't
include AUCTeX.

Re: deleting rcs keywords from emacs sources

[Robert J. Chassell]

   If you put a date manually into the files when you send an entire
   file to someone, it would achieve the same purpose, right?
   You'd be doing it manually instead of automatically.

   How much extra work would that impose on you?
   (It depends on how often you actually do this.)

Here is a function to insert the date at point.  I put it in my .emacs
file and use it all the time.

    ;;; Insert current date and, optionally, UTC time into current buffer
    (defun date (&optional full)
      "Insert current date; with optional arg, insert UTC time"
      (interactive "P")
      (if full
          ;; The third, last, optional, argument to format-time-string means
          ;; describe time as Universal Time; this may be labled GMT
          ;; rather than UTC.  2001 Aug 16: Gerd says
          ;;     This is a feature of the OS.  Strftime.c only adds a
          ;;     zone name when gmtime(3) doesn't already return one.
          ;; (format-time-string "%a, %Y %h %e  %H:%M %Z" nil t)
          (insert (format-time-string "%a, %Y %h %e  %H:%M %Z"))
        (insert (format-time-string "%Y %h %e"))))

For example, 

    M-x date  ==> 2004 Mar 26

C-u M-x date  ==> Fri, 2004 Mar 26  19:00 UTC

(I once formatted time strings as day - month - year, but then found
that I often need to see the year, so for this function and the way I
use it, the better format is year - month - day.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: deleting rcs keywords from emacs sources

[Andre Spiegel]

On Fri, 2004-03-26 at 17:45, Richard Stallman wrote:

> I can follow how this is useful for you.  I would guess that only a
> few Lisp file maintainers do this, though.

It may not be that common among Emacs maintainers, but as I said, it
surely is an essential feature in many other contexts.

> If you put a date manually into the files when you send an entire
> file to someone, it would achieve the same purpose, right?
> You'd be doing it manually instead of automatically.

It's doable, but it would be inconvenient.

How about this: CVS/RCS allows you to switch off keyword substitution by
default for each individual file.  The keywords are then only
substituted when somebody asks for it while checking out his personal
working copy.  This way, the files would contain unexpanded $Id$ headers
for everybody by default, but people like me who want and need them can
turn on keyword substitution locally for themselves.

How does that sound?

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

    > I can follow how this is useful for you.  I would guess that only a
    > few Lisp file maintainers do this, though.

    It may not be that common among Emacs maintainers, but as I said, it
    surely is an essential feature in many other contexts.

I see no reason to assume that RCS keywords in Emacs files are useful
to anyone in general.  You've said that those in VC files are useful
to some extent for you.

    > If you put a date manually into the files when you send an entire
    > file to someone, it would achieve the same purpose, right?
    > You'd be doing it manually instead of automatically.

    It's doable, but it would be inconvenient.

I asked that question so I can get an idea of how much
inconvenience it would be for you.

We could keep the keywords in the files you maintain, if the
inconvenience for you of removing them would be substantial.  But I
would like to see how much inconvenience we're talking about.

    How about this: CVS/RCS allows you to switch off keyword substitution by
    default for each individual file.  The keywords are then only
    substituted when somebody asks for it while checking out his personal
    working copy.

Maybe that would work ok.  In practice, I am not sure it is much better
than the other two alternatives.

Re: deleting rcs keywords from emacs sources

[Andre Spiegel]

On Sun, 2004-03-28 at 03:36, Richard Stallman wrote:

> I asked that question so I can get an idea of how much
> inconvenience it would be for you.

The time I would need to put a timestamp into a file before I send it to
someone is surely negligible.  I assume between 5-10 seconds.  Less than
that if I write myself a clever macro for it.  I'd be doing it between
5-10 times a year, so that's your absolute measure of "inconvenience".

The problem with this approach is that the files would only be stamped
when *I* send them out.  When somebody gets a file through a different
channel, e.g. via Web-CVS, or because somebody else sends it to him, the
file won't have an identification in it.

As a result, I might get bug reports where we unknowingly talk about
different versions of a file.  It might take considerable time to sort
out such a misunderstanding.  This is a more severe kind of
"inconvenience" than the time I would need to make a timestamp manually.

Even if everything goes well, there would now be several different ways
to determine the version of a file: If it's from an Emacs release, use
the ChangeLog and CVS history.  If you're hooked up to CVS, use the CVS
version information.  If you get it via another channel, hope that
somebody put a timestamp into it.

To me, that seems messy and an inconvenience in itself.

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

    The problem with this approach is that the files would only be stamped
    when *I* send them out.  When somebody gets a file through a different
    channel, e.g. via Web-CVS, or because somebody else sends it to him, the
    file won't have an identification in it.

Is it a frequent occurrence for you that people report problems in
versions that of VC they got from CVS in this way, without updating
Emacs as a whole from CVS?  Very few of the bug reports that I see
seem to describe such cases.

Re: deleting rcs keywords from emacs sources

[Andre Spiegel]

On Mon, 2004-03-29 at 22:56, Richard Stallman wrote:

>     The problem with this approach is that the files would only be stamped
>     when *I* send them out.  When somebody gets a file through a different
>     channel, e.g. via Web-CVS, or because somebody else sends it to him, the
>     file won't have an identification in it.
> 
> Is it a frequent occurrence for you that people report problems in
> versions that of VC they got from CVS in this way, without updating
> Emacs as a whole from CVS?  Very few of the bug reports that I see
> seem to describe such cases.

It is hard to tell how frequent this is, because in the past, the files
people were referring to always contained version numbers, and so I
wouldn't know which path they actually took.

Myself, I have just recently built and installed a CVS snapshot of Emacs
at a customer site, because we needed some of the new features that are
not in any actual release yet.  I would assume that such installations
occur frequently all over the world, especially since there is so much
time between Emacs releases.  The installed source files are indeed
disconnected from their CVS history.  Now, if anybody were to discover a
bug in such an installation, in a source file without version headers in
it, it would be difficult to track down.

I don't have hard numbers for this.  I'm referring to potential
problems, which might turn out more or less severe.  (If I'm anywhere
near correct, it ought to be happening already for other files, which I
don't maintain, and which never had version headers in them.  Only other
developers could testify to that.)

You say that "very few" of the bug reports you see seem to describe such
cases.  So, if it actually does occur, and version headers would help
with these cases, then that appears to be an argument to keep them, and
to solve the problems they cause by some other means.

Re: deleting rcs keywords from emacs sources

[Richard Stallman]

    You say that "very few" of the bug reports you see seem to describe such
    cases.  So, if it actually does occur, and version headers would help
    with these cases, then that appears to be an argument to keep them, and
    to solve the problems they cause by some other means.

They impose a substantial maintenance burden.  It is worth removing them
when we don't need them.

If you find them useful in VC, we can keep them in VC for you.

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 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

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....