source repository

source repository

[Paul Pogonyshev]

Hi,

What is the best way to stay in touch with Emacs development?  As I
understood, Emacs now uses Arch mostly, but when I checked out from
Arch (emacs--devo--0, is that the right name?), I got last change on
June 17, much earlier than in CVS...

Paul

Re: source repository

[Jason Rumney]

Paul Pogonyshev wrote:
> What is the best way to stay in touch with Emacs development?  As I
> understood, Emacs now uses Arch mostly,

You understood incorrectly. Some developers use arch, but the definitive 
repository for Emacs is CVS. Since Miles is away at the moment, the arch 
synching is not happening. I'm not sure why savannah lists arch above 
cvs (probably it is alphabetical order), but it is misleading - there 
should be some indication there that the main repository is CVS.

Re: source repository

[Paul Pogonyshev]

Jason Rumney wrote:
> Paul Pogonyshev wrote:
> > What is the best way to stay in touch with Emacs development?  As I
> > understood, Emacs now uses Arch mostly,
> 
> You understood incorrectly. Some developers use arch, but the definitive 
> repository for Emacs is CVS. Since Miles is away at the moment, the arch 
> synching is not happening. I'm not sure why savannah lists arch above 
> cvs (probably it is alphabetical order), but it is misleading - there 
> should be some indication there that the main repository is CVS.

Oh.  A pity Emacs still uses so old system.  I got used to Subversion
lately.

Paul

Re: source repository

[dhruva]

Hi,

On 7/3/07, Paul Pogonyshev <pogonyshev@gmx.net> wrote:
> Jason Rumney wrote:
> > Paul Pogonyshev wrote:
> > > What is the best way to stay in touch with Emacs development?  As I
> > > understood, Emacs now uses Arch mostly,
> >
> > You understood incorrectly. Some developers use arch, but the definitive
> > repository for Emacs is CVS. Since Miles is away at the moment, the arch
> > synching is not happening. I'm not sure why savannah lists arch above
> > cvs (probably it is alphabetical order), but it is misleading - there
> > should be some indication there that the main repository is CVS.
>
> Oh.  A pity Emacs still uses so old system.  I got used to Subversion
> lately.

If you are behind a firewall (the way I am), you could use Mercurial
repository which is updated daily from the CVS head. I use it for my
daily dosage of fresh emacs. Mercurial is implemented in python and is
well ported (IMHO: and far superior to other SCM)

repo: http://hg.intevation.org/emacs
Some basic commands:
First checkout:
$ hg clone http://hg.intevation.org/emacs
Subsequent updates:
$ hg pull -u

with best regards,
dky


-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: source repository

[Eli Zaretskii]

> From: Paul Pogonyshev <pogonyshev@gmx.net>
> Date: Tue, 3 Jul 2007 15:14:16 +0300
> Cc: Jason Rumney <jasonr@f2s.com>
> 
> > You understood incorrectly. Some developers use arch, but the definitive 
> > repository for Emacs is CVS. Since Miles is away at the moment, the arch 
> > synching is not happening. I'm not sure why savannah lists arch above 
> > cvs (probably it is alphabetical order), but it is misleading - there 
> > should be some indication there that the main repository is CVS.
> 
> Oh.  A pity Emacs still uses so old system.

Why should we care how old it is, if it suits our needs?  We are not
exactly spoiled by abundance of free resources to invest effort in
jobs that are ``nice to have''.  Just think how many man-hours will be
wasted if every Emacs developer and contributor will have to install,
learn, and set up an unfamiliar configuration management package.

Re: source repository

[Karl Fogel]

dhruva <dhruvakm@gmail.com> writes:
> On 7/3/07, Paul Pogonyshev <pogonyshev@gmx.net> wrote:
>> Jason Rumney wrote:
>> > Paul Pogonyshev wrote:
>> > > What is the best way to stay in touch with Emacs development?  As I
>> > > understood, Emacs now uses Arch mostly,
>> >
>> > You understood incorrectly. Some developers use arch, but the definitive
>> > repository for Emacs is CVS. Since Miles is away at the moment, the arch
>> > synching is not happening. I'm not sure why savannah lists arch above
>> > cvs (probably it is alphabetical order), but it is misleading - there
>> > should be some indication there that the main repository is CVS.
>>
>> Oh.  A pity Emacs still uses so old system.  I got used to Subversion
>> lately.
>
> If you are behind a firewall (the way I am), you could use Mercurial
> repository which is updated daily from the CVS head. I use it for my
> daily dosage of fresh emacs. Mercurial is implemented in python and is
> well ported (IMHO: and far superior to other SCM)
>
> repo: http://hg.intevation.org/emacs
> Some basic commands:
> First checkout:
> $ hg clone http://hg.intevation.org/emacs
> Subsequent updates:
> $ hg pull -u

Can I also commit through Mercurial, if I use this method?

Re: source repository

[Richard Stallman]

     I'm not sure why savannah lists arch above 
    cvs (probably it is alphabetical order), but it is misleading - there 
    should be some indication there that the main repository is CVS.

I wrote to the savannah hackers about this.
Thanks for pointing it out.

Re: source repository

[Richard Stallman]

    Oh.  A pity Emacs still uses so old system.  I got used to Subversion
    lately.

We did not switch to Subversion because the people who develop
Subversion are not sympathetic to the ideas of the free software
movement.  That is a sufficient reason, given that CVS works fine.

Re: source repository

[dhruva]

Hi,

On 7/4/07, Karl Fogel <kfogel@red-bean.com> wrote:
> Can I also commit through Mercurial, if I use this method?

No, it is a private repo (and I do not won it), it is a read only
access. If there was a read/write, you could but note that they will
not be carried to the main CVS repo of Emacs. If you do want to
maintain your own versioned changes, you could as the cloned copy will
have the complete revision history and a full blown self sufficient
mercurial repo (concept of D-SCM).

Once you have cloned the emacs repo... Use the mercurial "mq"
extension to maintain your local changes as patches on the original.
You can update on a frequency best suited for you and reapply you
local patches. This is the suggested work flow to work on 3rdparty
software. I use this approach for most of my minor tweaks. Once you
find them good enough for the general public, you could post your
diffs to the emacs list for possible inclusion.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: source repository

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Oh.  A pity Emacs still uses so old system.
 > 
 > Why should we care how old it is, if it suits our needs?

Because it doesn't suit your needs.  Didn't you just have a month of
acrimony over how to handle branching after the 22.1 release?  Don't
you still completely lack any policy about how things will be handled
in the future except "Richard will decide, after hearing the advice of
other developers"?  Doesn't that still bother at least a few of the
core developers?  Richard has said it's ok to merge multi-tty, but I
detect deep breaths around the table, as nobody is quite ready to go
put it in CVS.

*All* of that would be unnecessary with any modern dSCM, including the
deep breaths.  Anybody with 100MB (well, that's what XEmacs requires
w/o packages, so GNU Emacs might need 200MB?) of spare disk space can
do a trial merge with no risk.

 > We are not exactly spoiled by abundance of free resources to invest
 > effort in jobs that are ``nice to have''.

This is an investment with returns that Warren Buffett can only dream
of.

 > Just think how many man-hours will be wasted if every Emacs
 > developer and contributor will have to install, learn, and set up
 > an unfamiliar configuration management package.

Not so.  You were correct the first time: it's an "investment", not a
"waste".

The real issue is preserving history across the transition.  This is
costly in thought and time, and requires some effort, planning, and
trial-and-error by the staff.  But not that much; ask Miles---he
thought it was worth putting Emacs into Arch for personal use, AIUI,
then graciously offered it to the world.

As for the rest, a bridge from a dSCM to CVS is trivial; people who
checkout from CVS and mail patches can continue to do so.  (It does
require duplicate diskspace for the repository, of course.)

Installation of darcs, git, and mercurial are trivial[1] on all open
source systems that I use (GNU/Linux, NetBSD, Mac OS X/MacPorts).  I
assume that would extend to other GNU systems (including Cygwin and
perhaps MSYS), other *BSD, and Mac OS X/Fink.  Installation of git
from source on the open source systems I use was straightforward, as
it was on Solaris 9.  git and darcs may be hard to install from source
on non-POSIX systems, but Mercurial should be no problem (100% python).

Familiarity is not a problem as long as only one of the SCMs is chosen
as the official one.  The semantics of the commands corresponding to
checkout, update, and commit are similar at the level of what "every
Emacs developer and contributor" will have to learn.  Branching is
different, but perhaps more intuitive; however most contributors will
be working with the mainline, or perhaps Emacs 22, and will not need
to worry about it more than once in a year.

The people who do need to worry about the subtle semantic differences
across various systems are precisely the same people who will benefit
hugely from well-supported branching.  That's not a net cost, either.



Footnotes: 
[1]  Darcs installation can be very clock-time-consuming if you don't
already have Haskell (ghc) installed and are a build-from-source type.

Re: source repository

[Nick Roberts]

 >  > Just think how many man-hours will be wasted if every Emacs
 >  > developer and contributor will have to install, learn, and set up
 >  > an unfamiliar configuration management package.
 > 
 > Not so.  You were correct the first time: it's an "investment", not a
 > "waste".

It will be a waste if the chosen system becomes unsupported.  There seems to
have been an explosion of version control software recently, and presumably
some will sink into oblivion.  While CVS has undoubtedly presented problems,
they are small compared to more practical ones such as finding people with
the right skills who are willing to work unpaid on Emacs.

Personally, I would like to see us change to a distributed system but would
prefer to wait until there is one clear candidate.  I guess I could stand one
change, but two would be too many.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: source repository

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Oh.  A pity Emacs still uses so old system.  I got used to Subversion
>     lately.
>
> We did not switch to Subversion because the people who develop
> Subversion are not sympathetic to the ideas of the free software
> movement.  That is a sufficient reason, given that CVS works fine.

It doesn't for continuously managing multiple branches of development.
There is a reason why Miles does most of the work in that area using
arch.

And the sympathy of CVS developers does not buy us much when there is
no active development or bug fixes for our sakes.  Of course, we would
not want to depend on a system with unsympathetic developers when it
is likely that we will depend on their further support or when their
system is not licensed as free software (which more or less implies a
perpetual dependency).  The Linux/Bitkeeper situation was such a one.

I actually use the outcome of that clash, the git system, for managing
local multiple branches and merges, and it works quite well.  Since it
is completely decentralized (it does not require something like arch
tags and can even cater for the history of split files and functions
moved into different files), people can use it without the need of a
centralized repository.

However, git's exchange functions with Subversion are much better than
those interacting with CVS, so I actually prefer working on Subversion
to working on git, even though Subversion does not really offer better
merge support.

One major point going for git is merge tracking: it keeps track of how
you resolve merge failures, and can apply the same solution when
merging branches in a similar situation.

git's developers, it being the Linux kernel source management system,
are a diverse bunch, mostly tending to agnosticism towards the cause
of free software.  However, they are responsive about problem reports,
and they have to use the system actively to manage a large-scale
multi-person project with lots of branching and sand-boxed
development.  And git is released as free software (GPLv2 rather than
Subversion's Apache/BSD).  Personally, I consider the "anarchism" of
it, namely that it is actually more or less each developer's personal
choice, not dependent on a central repository, whether or not he uses
git for working with others and preparing patches, an advantage.

-- 
David Kastrup

Re: source repository

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  >  > Just think how many man-hours will be wasted if every Emacs
>  >  > developer and contributor will have to install, learn, and set up
>  >  > an unfamiliar configuration management package.
>  > 
>  > Not so.  You were correct the first time: it's an "investment", not a
>  > "waste".
>
> It will be a waste if the chosen system becomes unsupported.  There seems to
> have been an explosion of version control software recently, and presumably
> some will sink into oblivion.  While CVS has undoubtedly presented problems,
> they are small compared to more practical ones such as finding people with
> the right skills who are willing to work unpaid on Emacs.
>
> Personally, I would like to see us change to a distributed system
> but would prefer to wait until there is one clear candidate.  I
> guess I could stand one change, but two would be too many.

Well, the hallmark of a good distributed system should be that people
can use it or not, as they choose.  The question of policy mostly
arises for the central repository.  The choice of CVS does not lend
itself well to interfacing with distributed systems, and part of the
reason is that basically every file is an isolated repository, with
its isolated content, its isolated change history, and a permanently
fixed place in the work directory.  And every branch becomes an
isolated repository as well, with no tracking of merges taking place.
And CVS has no place in its repository to actually store such metadata
about a file contents origins and history.

-- 
David Kastrup

Re: source repository

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> We did not switch to Subversion because the people who develop
> Subversion are not sympathetic to the ideas of the free software
> movement.  

What?

I am a founding developer of Subversion.  Its other founding developer
is Jim Blandy, who worked for the Free Software Foundation and whose
devotion to free software is well known to you, Richard.  

The people who develop Subversion are no more a monolithic group than
the people who hack on GNU Emacs, and no more deserving of your
slander.  No, we don't make our developers sign certificates of
pure-heartedness before we accept their code contributions, but then
again neither does the FSF.  I don't know where you got this idea you
have about the Subversion team, but it's not right in the aggregate,
and is dead wrong about me in particular.  You're just carelessly
slinging around accusations based on vague impressions; it's
irresponsible and insulting.

-Karl

Re: source repository

[dhruva]

Hi,
 For someone like me with no write access to CVS (well, I do not need
for the trivial changes I make), a DSCM offers a mechanism to keep my
local changes under version control. This greatly helps preparing
localized (customized) packaging for our internal use. IMHO, this can
trigger more involvement as people can maintain their own changes
(_under_ _version_ _control__ and repeatedly apply them onto the
mainstream Emacs changes.
 Last but not the least, the firewall issue. Many companies block the
standard ports on which files can be exchanged. In most companies I
have worked so far, CVS port has been blocked (long back, Savannah was
running CVS on 443 and I could access). Also, CVS through PROXY is not
widely supported/used. I have just come across unofficial tweaks to
support that. Mercurial (I have not worked on other DSCM extensively
enough to have explored the various features) works on the standard
HTTP port, if you have web access, you have repository access. In my
view, this is also a very important feature.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: source repository

[David Kastrup]

dhruva <dhruvakm@gmail.com> writes:

> For someone like me with no write access to CVS (well, I do not need
> for the trivial changes I make), a DSCM offers a mechanism to keep
> my local changes under version control. This greatly helps preparing
> localized (customized) packaging for our internal use. IMHO, this
> can trigger more involvement as people can maintain their own
> changes (_under_ _version_ _control__ and repeatedly apply them onto
> the mainstream Emacs changes.

Personally, I don't think that any current dSCM has seen much
large-scale project exposure and can at the same time be considered
stable and available cross-platform.

On my personal list of systems, git probably comes closest: it
certainly is there to stay, even though it is still undergoing quite a
bit of development.  And its being used for Linux kernel development
means that its problems are similar to ours.

The main crucial difference in our target clientele is that for git
developers, MS Windows is mostly off the radar.  The available Cygwin
port is bulky and comparatively slow.

-- 
David Kastrup

Re: source repository

[Jim Blandy]

Richard Stallman <rms@gnu.org> writes:
> We did not switch to Subversion because the people who develop
> Subversion are not sympathetic to the ideas of the free software
> movement.

Why do you say this?

I am one of the founding developers of Subversion.  I've worked on
nothing but Free software my entire career.  I've been a maintainer of
GNU Emacs, Guile, and GDB.  I've been to Japan three or four times to
give talks and appear at trade shows to raise funds for the Free
Software Foundation.  It is completely untrue that I am not
sympathetic to the ideas of the free software movement.

Re: source repository

[Stephen J. Turnbull]

Nick Roberts writes:

 > It will be a waste if the chosen system becomes unsupported.

Both git and Mercurial are quite mature, and eminently maintainable in
the very unlikely chance that either becomes unsupported.

 > some will sink into oblivion.  While CVS has undoubtedly presented
 > problems, they are small compared to more practical ones such as
 > finding people with the right skills who are willing to work unpaid
 > on Emacs.

Pay is not why I don't work on Emacs (much, directly).  Although
unwillingness to wrestle CVS is not the main reason, I would be *far*
more likely to work on Emacs directly more often if the personal cost
of keeping a repo up-to-date were negligible, and the cost of
communicating a working version of Emacs containing my contributions
to others were small.  How many developers are in this boat, I don't
know.  Can Emacs afford to ignore even one?

 > Personally, I would like to see us change to a distributed system
 > but would prefer to wait until there is one clear candidate.  I
 > guess I could stand one change, but two would be too many.

There will not be one clear candidate for many years, if ever, but
there will nonetheless be no reason to change again project-wide for
quite a while.  As David Kastrup has pointed out, the "d" stands for
"distributed", and therefore there must be a well-defined protocol for
communicating full metadata among repositories.  Neither subversion
nor CVS has that, really, but all of the dSCMs do, and they agree to a
remarkable extent on what the needed metadata is.

This is not just theory; there are already many conversion tools
available, and dSCM being what it is and free software developers
being what they are, the (small) burden of converting to Yet Another
SCM can be amortized over the group of enthusiasts for that SCM.  The
project just continues with whatever it had been using for archival
and distribution purposes.

My personal recommendation at the present time for projects is
Mercurial, because portability issues can be delegated to Guido van
Rossum and the rest of the very capable Python crew.  git is obviously
going to work better on Linux than anywhere else for a while, and it's
not obvious that darcs is going to work well anywhere at the moment.

Footnotes: 
[1]  Of course this would require some work by FSF legal, but I see no
reason why it would be impossible to write an appropriate assignment
instrument, and enforce it with appropriate commit hooks.

Re: source repository

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Paul Pogonyshev <pogonyshev@gmx.net>
  > > Date: Tue, 3 Jul 2007 15:14:16 +0300
  > > Cc: Jason Rumney <jasonr@f2s.com>
  > > 
  > > > You understood incorrectly. Some developers use arch, but the definitive 
  > > > repository for Emacs is CVS. Since Miles is away at the moment, the arch 
  > > > synching is not happening. I'm not sure why savannah lists arch above 
  > > > cvs (probably it is alphabetical order), but it is misleading - there 
  > > > should be some indication there that the main repository is CVS.
  > > 
  > > Oh.  A pity Emacs still uses so old system.
  > 
  > Why should we care how old it is, if it suits our needs?  We are not
  > exactly spoiled by abundance of free resources to invest effort in
  > jobs that are ``nice to have''.  Just think how many man-hours will be
  > wasted if every Emacs developer and contributor will have to install,
  > learn, and set up an unfamiliar configuration management package.

Well, one thing that is missing in emacs right now for most version
control is something similar to PCL-CVS. That would make life much
easier for emacs developers not really familiar with a particular
version control system. And on top of that, it would be extremely
useful for all emacs users. 

Re: source repository

[Alan Mackenzie]

On Tue, Jul 03, 2007 at 12:57:11PM +0100, Jason Rumney wrote:
> I'm not sure why savannah lists arch above cvs ....

These days, all sorts of things arch above CVS.  Why should savannah
lists be any different?  ;-)

-- 
Alan.

Re: source repository

[Masatake YAMATO]

>   > > From: Paul Pogonyshev <pogonyshev@gmx.net>
>   > > Date: Tue, 3 Jul 2007 15:14:16 +0300
>   > > Cc: Jason Rumney <jasonr@f2s.com>
>   > > 
>   > > > You understood incorrectly. Some developers use arch, but the definitive 
>   > > > repository for Emacs is CVS. Since Miles is away at the moment, the arch 
>   > > > synching is not happening. I'm not sure why savannah lists arch above 
>   > > > cvs (probably it is alphabetical order), but it is misleading - there 
>   > > > should be some indication there that the main repository is CVS.
>   > > 
>   > > Oh.  A pity Emacs still uses so old system.
>   > 
>   > Why should we care how old it is, if it suits our needs?  We are not
>   > exactly spoiled by abundance of free resources to invest effort in
>   > jobs that are ``nice to have''.  Just think how many man-hours will be
>   > wasted if every Emacs developer and contributor will have to install,
>   > learn, and set up an unfamiliar configuration management package.
> 
> Well, one thing that is missing in emacs right now for most version
> control is something similar to PCL-CVS. That would make life much
> easier for emacs developers not really familiar with a particular
> version control system. And on top of that, it would be extremely
> useful for all emacs users. 

DVC does similar to PCL-CVS for distributed version control systems.
I was working on the xtla, the ancestor of DVC. 

  http://dl.gna.org/dvc/

I was interested in merge DVC to GNU Emacs. However, these days, I am
busy and I get interests to extend vc-dired, so I've just asked DVC
developers to assign another people for working on the merging task.

Masatake YAMATO

Re: source repository

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
> Cc: Paul Pogonyshev <pogonyshev@gmx.net>,
>     emacs-devel@gnu.org
> Date: Wed, 04 Jul 2007 13:26:00 +0900
> 
> Didn't you just have a month of
> acrimony over how to handle branching after the 22.1 release?

People like talking, so they talked for a long time.  I didn't see any
acrimony in that; I barely read the thread.

> Don't you still completely lack any policy about how things will be
> handled in the future except "Richard will decide, after hearing the
> advice of other developers"?

I don't see how a piece of software, any software, can resolve
personal problems of this kind.

Re: source repository

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
>> Cc: Paul Pogonyshev <pogonyshev@gmx.net>,
>>     emacs-devel@gnu.org
>> Date: Wed, 04 Jul 2007 13:26:00 +0900
>> 
>> Didn't you just have a month of
>> acrimony over how to handle branching after the 22.1 release?
>
> People like talking, so they talked for a long time.  I didn't see any
> acrimony in that; I barely read the thread.
>
>> Don't you still completely lack any policy about how things will be
>> handled in the future except "Richard will decide, after hearing the
>> advice of other developers"?
>
> I don't see how a piece of software, any software, can resolve
> personal problems of this kind.

Actually, it is quite instructive how git does this in Linux kernel
development: most kernel developers maintain their own version of the
kernel and push around patches.  Some people collect and integrate a
variety of patches from different people according to their trust
metrics and have their own kernel series (like an
Andrew-Morton-kernel).  Kernel integrators integrate what they
consider useful patches.  Linus Torvalds is responsible for the
"canonical" kernel and merges hundreds of patches and patch sets per
week.  patch sets get signed off by people who consider them useful.
The actual act of merging, due to git keeping track of the conflicts
and diversions in branches and how they were resolved, is rather
painless for pretty much everybody.

At any point of time, there are literally hundreds of parallel
versions and branches from different people.  Consequently, there is
no discussion about what people might be allowed to merge when into
what branch: somebody wanting to test a particular functionality will
pull from the corresponding server of the particular developer, teach
his repository how to deal with conflicts in unrelated areas (likely
by backing out particular branches/change sets/whatever), and then be
able to track the functionalities he likes in his own branch.

So while git does not actually _resolve_ personal conflicts about what
we would like to have in the canonical Emacs, it allows postponing the
resolution for several parallel development lines almost indefinitely,
and everybody gets to play with everything he considers worth playing
with without having to have this centrally managed.  This obliterates
a whole bunch of pleading wars.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: source repository

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Don't you still completely lack any policy about how things will be
 > > handled in the future except "Richard will decide, after hearing the
 > > advice of other developers"?

 > I don't see how a piece of software, any software, can resolve
 > personal problems of this kind.

It's not a "personal problem", it's Richard's style, reflecting his
constraints as a manager with many responsibilities besides Emacs.  If
it works for him as maintainer, and Richard as maintainer works for
the developers, where's any "problem"?

But there is an *opportunity* to improve here.

How could a better SCM help to improve the process?  The point is that
with a SCM which has no concept of "trunk" and which is very helpful
to merges among branches, the maintainer's decision timing becomes
irrelevant to communication of on-going development among the regular
developers.  The limiting factor becomes an individual's resources to
manage her own workspaces rather than the maintainer's decision to
open or close a primary channel of communication.  It also enables
workers who are only weakly connected to the Internet to keep
reasonably up-to-date with *all* branches, and have *full* access to
history and other metadata even though the official repository is
inconvenient or inaccessible.

These primary channels, ie the nominal trunk and the release process,
will remain the primary channels to the outside world, and remain
under control of the maintainer.  However, by using an appropriate
SCM, it is possible to separate the issue of day-to-day communication
among developers from the issue of what to release when.

Re: source repository

[Richard Stallman]

      I don't know where you got this idea you
    have about the Subversion team, but it's not right in the aggregate,
    and is dead wrong about me in particular.

I am not talking about anyone in particular.

      You're just carelessly
    slinging around accusations based on vague impressions;

It is not meant as an accusation, and they are not my own impressions.

Several years ago there was a suggestion to use Subversion in some
major way on Savannah.  People (I don't recall who) looked at the
situation and reported that the Subversion developers did not support
us as we wished, so we did not promote it.

It's possible I misremembered what they reported a few years ago.  If
so, I apologize.  Before today I did not know who Subversion
developers were.  You and Jim are certainly free software supporters.
I don't know whether Subversion as a project supports free software
and GNU the way you personally have.

Re: source repository

[Richard Stallman]

      How many developers are in this boat, I don't
    know.  Can Emacs afford to ignore even one?

There's more at stake here than a few developers more or less.
And some of it is imponderable, such as this:

    [1]  Of course this would require some work by FSF legal, but I see no
    reason why it would be impossible to write an appropriate assignment
    instrument, and enforce it with appropriate commit hooks.

To think about this would take a lot of time, and it would be easy
to be wrong.  There is no need to spend time and take a risk
where nothing is actually broken.

The easy thing to do is to stay with CVS, so we will do that.

I will ask the savannah hackers and sysadmins to look at making
port 443 access available again.  That would help some people
and doesn't raise any hard issues.

Re: source repository

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> Several years ago there was a suggestion to use Subversion in some
> major way on Savannah.  People (I don't recall who) looked at the
> situation and reported that the Subversion developers did not support
> us as we wished, so we did not promote it.
>
> It's possible I misremembered what they reported a few years ago.  If
> so, I apologize.  Before today I did not know who Subversion
> developers were.  You and Jim are certainly free software supporters.
> I don't know whether Subversion as a project supports free software
> and GNU the way you personally have.

Subversion supports free software no less than CVS does (both Jim and
I have been on both teams), insofar as such things can be measured.

So if that report from long ago remains the reason you don't use
Subversion on Savannah, then it's time to reconsider.  You now have
credible sources telling you the report was wrong.

Not that I'm pushing Subversion.  If Emacs switched to Mercurial or
GIT I'd be just as happy; CVS is getting in our way, for reasons
others have explained at length already.

Re: source repository

[Yavor Doganov]

Karl Fogel wrote:
> 
> So if that report from long ago remains the reason you don't use
> Subversion on Savannah, then it's time to reconsider.

TTBOMK nothing of that kind stops implementing Subversion support at
Savannah.  The obstacles are purely technical [1].  

Maybe RMS meant git?  His statement would be very true in this case.
Either way, Savannah has git support [2] now along with CVS and GNU
Arch.

[1] https://savannah.gnu.org/maintenance/WhenSvN
[2] http://savannah.gnu.org/maintenance/UsingGit

merge of multi-tty (was: source repository)

[Reiner Steib]

On Wed, Jul 04 2007, Stephen J. Turnbull wrote:

> Richard has said it's ok to merge multi-tty, but I detect deep
> breaths around the table, as nobody is quite ready to go put it in
> CVS.

I can image that Miles would like to do this via arch when he's back
from holidays.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

merge of multi-tty (was: source repository)

[Stephen J. Turnbull]

Reiner Steib writes:

 > On Wed, Jul 04 2007, Stephen J. Turnbull wrote:
 > 
 > > Richard has said it's ok to merge multi-tty, but I detect deep
 > > breaths around the table, as nobody is quite ready to go put it in
 > > CVS.
 > 
 > I can image that Miles would like to do this via arch when he's back
 > from holidays.

*grin*  Somebody gets it.

Re: merge of multi-tty (was: source repository)

[Richard Stallman]

    I can image that Miles would like to do this via arch when he's back
    from holidays.

It is ok if Miles does this, but it is ok for someone else who understands
the code to do it first.

Re: merge of multi-tty

[Stefan Monnier]

>     I can image that Miles would like to do this via arch when he's back
>     from holidays.

> It is ok if Miles does this, but it is ok for someone else who understands
> the code to do it first.

Actually, there a little misunderstanding: we don't need Miles to do it on
the Arch side: anybody can do it instead of Miles.  But it's important to do
it on the Arch side because Arch does keep track of the information relative
to which merges happened when between which branches whereas CVS doesn't.


        Stefan

Re: merge of multi-tty

[Richard Stallman]

When changes are entered thru Arch, what do the change logs look like
in CVS?

Re: source repository

[Giorgos Keramidas]

On 2007-07-04 13:26, "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> wrote:
>Eli Zaretskii writes:
>>> Oh.  A pity Emacs still uses so old system.
>>
>> Why should we care how old it is, if it suits our needs?
>
> Because it doesn't suit your needs.

I don't want to argue about this.  There are practices in the main Emacs
development team, which may not map so well in a dSCM, so let's leave
this for another 'flame' :-)

> *All* of that would be unnecessary with any modern dSCM, including the
> deep breaths.  Anybody with 100MB (well, that's what XEmacs requires
> w/o packages, so GNU Emacs might need 200MB?) of spare disk space can
> do a trial merge with no risk.

More like 120 MB.  I keep a local conversion of the CVS 'HEAD' branch on
my laptop, and the repository data of the branch in Mercurial needs
slightly more than 120 MB for the full history of the 'HEAD' branch.
A second clone uses less space (probably because of optimizations in the
clone operation):

  $ pwd
  /home/keramida/hg/emacs
  $ du -sk gnu/.hg gker/.hg
  127464  gnu/.hg
  74076   gker/.hg
  $

>> We are not exactly spoiled by abundance of free resources to invest
>> effort in jobs that are ``nice to have''.
>
> This is an investment with returns that Warren Buffett can only dream
> of.

Eli is right that some non-negligible amount of 'retraining' will be
needed though.  No investment comes without at least some cost :-/

> Familiarity is not a problem as long as only one of the SCMs is chosen
> as the official one.

This is theoretically true.  It's nice to avoid gratuitous breakage in
scripts and brain-investment in vc-mode learning though.  Right now, CVS
has excellent support in vc-mode.  The CVS support has been tested and
deployed in hundreds of places around the world for several years.

Mercurial support, on the other hand, is only in CVS 'HEAD' and it is
being tested (by yours truly, among others).  It has only been in the
repository for a few weeks, and there may be still be some rough edges.

Sometimes, it's all about familiarity and ease of use :-)

- Giorgos

Re: source repository

[dhruva]

Hello,

On 7/17/07, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:

> Mercurial support, on the other hand, is only in CVS 'HEAD' and it is
> being tested (by yours truly, among others).  It has only been in the

I guess even CVS support was in the same state _once upon a time_.
But, see it now. It is accepted by all (almost). We could atleast hope
for a similar turn of fate even for mercurial (or any other dSCM).

> repository for a few weeks, and there may be still be some rough edges.

That is only about the Emacs frontend to Mercurial (or any other
dSCM). Hope it does not reflect the underlying dSCM itself.

Anyway, I personally feel that we could atleast have a 1 way mirror
(initially) to allow a sort of beta phase. If things workout in the
long run, make the big move. If not, we can continue the read-only
repo for access to some of us (firewall restrictions). One could argue
about "why" we cannot maintain our own mirror. This will suffer from
the update frequency. If it is done officially, the CVS hooks could
trigger the incremental mirroring.

-dky


-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: source repository

[Giorgos Keramidas]

On 2007-07-17 14:45, dhruva <dhruvakm@gmail.com> wrote:
>  Hello,
>
>  On 7/17/07, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>
> > Mercurial support, on the other hand, is only in CVS 'HEAD' and it is
> > being tested (by yours truly, among others).  It has only been in the
>
>  I guess even CVS support was in the same state _once upon a time_.
>  But, see it now. It is accepted by all (almost). We could atleast hope
>  for a similar turn of fate even for mercurial (or any other dSCM).
>
> > repository for a few weeks, and there may be still be some rough edges.
>
>  That is only about the Emacs frontend to Mercurial (or any other
>  dSCM). Hope it does not reflect the underlying dSCM itself.

Indeed, I was referring to the Emacs frontend to Mercurial/Hg---not to
the dSCM itself.

> Anyway, I personally feel that we could atleast have a 1 way mirror
> (initially) to allow a sort of beta phase. If things workout in the
> long run, make the big move. If not, we can continue the read-only
> repo for access to some of us (firewall restrictions). One could argue
> about "why" we cannot maintain our own mirror. This will suffer from
> the update frequency. If it is done officially, the CVS hooks could
> trigger the incremental mirroring.

There is nothing that can stop people from `cloning' the existing Hg
repository (read-only), and setting up their own inter-person
collaboration :-)

vc-dired (was: Re: source repository)

[Dan Nicolaescu]

Masatake YAMATO <jet@gyve.org> writes:

  > I was interested in merge DVC to GNU Emacs. However, these days, I am
  > busy and I get interests to extend vc-dired, so I've just asked DVC
  > developers to assign another people for working on the merging task.

Given that you are interested in vc-dired, can you please look into
these issues: 

- pass --ignore= to ls so that it does not recurse into things like
  .svn directories

- If vc-dired dot show any files it displays the message: "No files
  locked under DIRNAME". I suppose the "locked" terminology comes from
  RCS, and it probably does not mean anything to most people
  nowadays. 

Thanks

        --dan

Re: vc-dired

[Masatake YAMATO]

>   > I was interested in merge DVC to GNU Emacs. However, these days, I am
>   > busy and I get interests to extend vc-dired, so I've just asked DVC
>   > developers to assign another people for working on the merging task.
> 
> Given that you are interested in vc-dired, can you please look into
> these issues: 
> 
> - pass --ignore= to ls so that it does not recurse into things like
>   .svn directories
> 
> - If vc-dired dot show any files it displays the message: "No files
>   locked under DIRNAME". I suppose the "locked" terminology comes from
>   RCS, and it probably does not mean anything to most people
>   nowadays. 

O.K. I'll take a look for these issues.
Give me time. A bit busy now.


Masatake YAMATO

Re: vc-dired

[Stefan Monnier]

>> I was interested in merge DVC to GNU Emacs. However, these days, I am
>> busy and I get interests to extend vc-dired, so I've just asked DVC
>> developers to assign another people for working on the merging task.

> Given that you are interested in vc-dired, can you please look into
> these issues: 

> - pass --ignore= to ls so that it does not recurse into things like
>   .svn directories

At least the vc.el part of VC should simply not use `ls' or any such thing
and shouldn't recurse into directories.  It should simply ask the backend to
do it (the backend can then use "cvs -n update" or "svn status" ...).
That'll be blindingly faster.


        Stefan

Re: vc-dired

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> I was interested in merge DVC to GNU Emacs. However, these days, I am
  > >> busy and I get interests to extend vc-dired, so I've just asked DVC
  > >> developers to assign another people for working on the merging task.
  > 
  > > Given that you are interested in vc-dired, can you please look into
  > > these issues: 
  > 
  > > - pass --ignore= to ls so that it does not recurse into things like
  > >   .svn directories
  > 
  > At least the vc.el part of VC should simply not use `ls' or any such thing
  > and shouldn't recurse into directories.  It should simply ask the backend to
  > do it (the backend can then use "cvs -n update" or "svn status" ...).
  > That'll be blindingly faster.

I would go even farther, IMVHO the "dired" part of the interface for
vc-dired is not that useful: the 4 top-level menu entries are not very
useful in the VC context, there's no top level menu for VC operations
and the files not under VC are not shown by default (it would be good
to see them so they can be vc-registered if desired).
It seems to me that a cvs-status like UI would be preferable to
vc-dired.

Re: vc-dired

[Masatake YAMATO]

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>   > >> I was interested in merge DVC to GNU Emacs. However, these days, I am
>   > >> busy and I get interests to extend vc-dired, so I've just asked DVC
>   > >> developers to assign another people for working on the merging task.
>   > 
>   > > Given that you are interested in vc-dired, can you please look into
>   > > these issues: 
>   > 
>   > > - pass --ignore= to ls so that it does not recurse into things like
>   > >   .svn directories
>   > 
>   > At least the vc.el part of VC should simply not use `ls' or any such thing
>   > and shouldn't recurse into directories.  It should simply ask the backend to
>   > do it (the backend can then use "cvs -n update" or "svn status" ...).
>   > That'll be blindingly faster.
> 
> I would go even farther, IMVHO the "dired" part of the interface for
> vc-dired is not that useful: the 4 top-level menu entries are not very
> useful in the VC context, there's no top level menu for VC operations
> and the files not under VC are not shown by default (it would be good
> to see them so they can be vc-registered if desired).
> It seems to me that a cvs-status like UI would be preferable to
> vc-dired.

Here is the first very small patch.
Do you think menu item "Version Control" is too long? 
"VC" is better?

Reorganizing the the 4 top-level is not done yet. I think we have to 
think about integrating version control own command and the menu entries.

     svn rm and "Operate"=>"Rename To" menu item.

In a directory which is version-control'ed by svn, vc-dired user may
expect "svn rm" is run when s/he invoke "Operate"=>"Rename To" menu
item.

Index: vc.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/vc.el,v
retrieving revision 1.444
diff -c -F define-derived-mode -r1.444 vc.el
*** vc.el	26 Jul 2007 18:44:37 -0000	1.444
--- vc.el	28 Jul 2007 06:59:09 -0000
***************   ;; define-derived-mode does it for us 
*** 2192,2197 ****
--- 2192,2201 ----
    ;; We do it here because dired might not be loaded yet
    ;; when vc-dired-mode-map is initialized.
    (set-keymap-parent vc-dired-mode-map dired-mode-map)
+   ;; Add menu after `vc-dired-mode-map' has `dired-mode-map' as the parent.
+   (let ((vc-dire-menu-map (copy-keymap vc-menu-map)))
+     (define-key-after (lookup-key vc-dired-mode-map [menu-bar]) [vc] 
+       (cons "Version Control" vc-dire-menu-map) 'subdir))
    (add-hook 'dired-after-readin-hook 'vc-dired-hook nil t)
    ;; The following is slightly modified from files.el,
    ;; because file lines look a bit different in vc-dired-mode

Re: vc-dired

[David Kastrup]

Masatake YAMATO <jet@gyve.org> writes:

>> I would go even farther, IMVHO the "dired" part of the interface for
>> vc-dired is not that useful: the 4 top-level menu entries are not very
>> useful in the VC context, there's no top level menu for VC operations
>> and the files not under VC are not shown by default (it would be good
>> to see them so they can be vc-registered if desired).
>> It seems to me that a cvs-status like UI would be preferable to
>> vc-dired.
>
> Here is the first very small patch.
> Do you think menu item "Version Control" is too long? 
> "VC" is better?

"VC" is not an established acronym (see the long list at
<URL:http://en.wikipedia.org/wiki/VC>).  "VCS"
<http://en.wikipedia.org/wiki/VCS> and "SCM"
<URL:http://en.wikipedia.org/wiki/Scm> at least get mentioned.  The
latter is probably the most widely used one, though it can be confused
with Scheme or a particular interpreter of it.

Short of an acronym, "Versioning" or "Version" might be possible.  For
registered files, using the version control system name itself might
be the way to go.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vc-dired

[Dan Nicolaescu]

Masatake YAMATO <jet@gyve.org> writes:

  > > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > > 
  > >   > >> I was interested in merge DVC to GNU Emacs. However, these days, I am
  > >   > >> busy and I get interests to extend vc-dired, so I've just asked DVC
  > >   > >> developers to assign another people for working on the merging task.
  > >   > 
  > >   > > Given that you are interested in vc-dired, can you please look into
  > >   > > these issues: 
  > >   > 
  > >   > > - pass --ignore= to ls so that it does not recurse into things like
  > >   > >   .svn directories
  > >   > 
  > >   > At least the vc.el part of VC should simply not use `ls' or any such thing
  > >   > and shouldn't recurse into directories.  It should simply ask the backend to
  > >   > do it (the backend can then use "cvs -n update" or "svn status" ...).
  > >   > That'll be blindingly faster.
  > > 
  > > I would go even farther, IMVHO the "dired" part of the interface for
  > > vc-dired is not that useful: the 4 top-level menu entries are not very
  > > useful in the VC context, there's no top level menu for VC operations
  > > and the files not under VC are not shown by default (it would be good
  > > to see them so they can be vc-registered if desired).
  > > It seems to me that a cvs-status like UI would be preferable to
  > > vc-dired.
  > 
  > Here is the first very small patch.
  > Do you think menu item "Version Control" is too long? 
 > "VC" is better?

I would think the former. Why don't you just pick one, we can fix it
later if needed.

  > Reorganizing the the 4 top-level is not done yet. I think we have to 
  > think about integrating version control own command and the menu entries.
  > 
  >      svn rm and "Operate"=>"Rename To" menu item.
  > 
  > In a directory which is version-control'ed by svn, vc-dired user may
  > expect "svn rm" is run when s/he invoke "Operate"=>"Rename To" menu
  > item.

Right. This is one of the reasons why in a previous message I said
that having this mode derived from dired might not be the best idea:
not all dired operations are desirable for version controlled files...

Re: vc-dired

[Masatake YAMATO]

> Short of an acronym, "Versioning" or "Version" might be possible.  For
> registered files, using the version control system name itself might
> be the way to go.

Thank you for good suggestion. I've just installed such modification.

I've remembered that I did do the same on the mode name of
vc-dired-mode appeared on the mode line.

Masatake YAMATO

Re: vc-dired

[Dan Nicolaescu]

Masatake YAMATO <jet@gyve.org> writes:

  > >   > I was interested in merge DVC to GNU Emacs. However, these days, I am
  > >   > busy and I get interests to extend vc-dired, so I've just asked DVC
  > >   > developers to assign another people for working on the merging task.
  > > 
  > > Given that you are interested in vc-dired, can you please look into
  > > these issues: 
  > > 
  > > - pass --ignore= to ls so that it does not recurse into things like
  > >   .svn directories
  > > 
  > > - If vc-dired dot show any files it displays the message: "No files
  > >   locked under DIRNAME". I suppose the "locked" terminology comes from
  > >   RCS, and it probably does not mean anything to most people
  > >   nowadays. 
  > 
  > O.K. I'll take a look for these issues.
  > Give me time. A bit busy now.

Here's another issue to consider:

This code in vc-dired-hook: 

         ;; ordinary file
         ((and (vc-backend filename)
                (not (and vc-dired-terse-mode
                           (vc-up-to-date-p filename))))
          (vc-dired-reformat-line (vc-call dired-state-info filename))
          (forward-line 1))

Is the vc-backend call necessary? It ends up calling vc-registered and
that can be expensive for the backends that run a program to determine
that. The -dir-state method computes the state for most (all?)
files... 
I don't understand this code very well, but if it can be simplified,
it might result in a significant speedup for vc-dired.

Can you please take a look? 

Thanks

        --dan