Re: Improving Emacs for writing code

[Stefan Monnier]

>   If it is possible to do a merge where the active truth is in the
> CEDET sourceforge repository, that would likely make things much
> easier for me in the short term.  When everyone feels it's "ready",
> then I'll update my disclaimer, and it could be moved to it's new
> home.

I suggest the following:
1 - make a local branch of Emacs using Bzr or Git.
3 - install CEDET inside it.
2 - publish it.

With those tools, merging changes from Emacs's trunk is about as hard as:

     % bzr merge --show-base
     ...resolve conflicts...
     % bzr commit -m 'Merge from trunk'

People can then try out "Emacs+CEDET" from your tree and send you
patches to install.  Once it looks good enough, you can get the
paperwork and we then install it into Emacs's CVS.

>   Unfortunately, merging the build harness will not be easy, or really
> possible in CEDET CVS tree since a goal for me will be at least one
> more CEDET release for older Emacsen.

As Chong explained, compatibility code is fine.  But you may be
referring to the tricker part of all the install&build scripts, which
will indeed be quite different.  You could install those scripts into
an emacs/admin/cedet directory (the `admin' subdir is not included in
the Emacs tarballs).

>   Then there is the ongoing maintenance.  I'm not sure how Stefan's
> suggestion would work for me.  I can imagine it being ok for a while
> when all the changes are small.  I believe in periodic refactoring
> which would make this more challenging.  If some smallish utility
> outgrows its original purpose, I'll start moving and renaming large
> chunks of code so things are more clear.  This would make
> cross-merging difficult soon afterward.

When cross-merging gets difficult, it's time to sync again: get the
new paperwork and update the Emacs-CVS.

>   There are also issues with the build harness, and how someone would
> use the most recent "Eric" version against the most recent "Emacs"
> version.

Just make sure you split your files into 3 disjoint sets:
1 - files used for all versions.
2 - files used only for the version bundled with Emacs.
2 - files used only for the unbundled version.

>   I would very much like to find a way to have a single VC truth where
> I can hack freely without impinging the rest of Emacs.  I can imagine
> two ways to do this:

> 1) Truth is in the Emacs, and I find some way to participate there, or
>    there is a branch where I can work.

As long as you can't get time-unbound paperwork, I'm afraid you won't be
able to work directly on the main Emacs branch.

But with distributed revision control you can have your own branch
of Emacs with 100% complete control over it, but with all the
merge&change tracking done as if it were within the same repository.

> 2) Truth is in SourceForge, and changes by Emacs developers are
>    checked into SourceForge.

Some developers may be willing to do that, but some changes will be done
on the Emacs trunk.  So you'll need to merge changes from Emacs's trunk
every once in a while.  IIUC Sourceforge only provides CVS and SVN
services, and merging between repositories using those VCS is rather
painful, so I recommend you use something else.

>    I'd then need to find a way to get
>    releases that allow a periodic mass-copy into the Emacs tree.

That's a given, no matter what setup we end up using.


        Stefan