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