CEDET sync

CEDET sync

[Stefan Monnier]

> Could you take a look at this report about a symbol that Semantic can't
> handle?  I just applied your semantic-lex-spp-table-write-slot-value
> change that saves a nil instead of erroring on invalid values.

BTW Eric, but it seems that Emacs's CEDET code and your own aren't being
sync'ed at all, is that right?  If so, we really need to get this syncing
going ASAP, otherwise it will be hellish to maintain.


        Stefan

Re: CEDET sync

[Eric M. Ludlam]

On 06/04/2010 09:07 AM, Stefan Monnier wrote:
>> Could you take a look at this report about a symbol that Semantic can't
>> handle?  I just applied your semantic-lex-spp-table-write-slot-value
>> change that saves a nil instead of erroring on invalid values.
>
> BTW Eric, but it seems that Emacs's CEDET code and your own aren't being
> sync'ed at all, is that right?  If so, we really need to get this syncing
> going ASAP, otherwise it will be hellish to maintain.

Hi,

A volunteer (Lluis) pulled in some recent Emacs changes.  Otherwise I 
agree about a more consistent sync.  I even have a loose plan.  It's 
just slow going.  Winter between November and mid-March is usually when 
I have the most Emacs hacking time.

If someone who knows some about dvcs systems I can use on Source Forge 
that would aid in such a sync system would like to help me set things 
up, that would be a huge boon for me!

Thanks
Eric

Re: CEDET sync

[Lluís]

>>> Could you take a look at this report about a symbol that Semantic can't
>>> handle?  I just applied your semantic-lex-spp-table-write-slot-value
>>> change that saves a nil instead of erroring on invalid values.
>> 
>> BTW Eric, but it seems that Emacs's CEDET code and your own aren't being
>> sync'ed at all, is that right?  If so, we really need to get this syncing
>> going ASAP, otherwise it will be hellish to maintain.

> If someone who knows some about dvcs systems I can use on Source Forge 
> that would aid in such a sync system would like to help me set things 
> up, that would be a huge boon for me!

Problem is, I didn't see a clear and hassle-free path to do cross-project
merging in the long term (I didn't ask the GNUS people about their strategy).

Right now I don't have much time to start playing with different VCS and
cross-merging strategies (I'm only proficient with subversion), but if any of
you come up with something that that would work with minimal user intervention
I'd be glad to start a new CEDET branch in such a scenario.

The first step I could do is renaming files, which is the major showstopper
right now. Then the real cross-merging could start, which I don't know if I
would have time to do.

As I understood it, the most viable cross-merging strategy would be:

   emacs           cedet
   |- trunk        |- trunk
   \- <branchN>    \- branch-emacs-<branchN>

Valid merging flows:

  cedet::*                    <-> cedet::*
  emacs::*                    <-> emacs::*
  emacs::trunk/lisp/cedet     <-  cedet::emacs-trunk
  emacs::<branchN>/lisp/cedet <-  cedet::emacs-<branchN>

My concern with such a scheme is how (*) to transplant changes from cedet into
an emacs subdirectory, such that all cedet commit logs and dates are maintained.

(*) which VCS can be used and which restrictions might this impose on the
    development workflow


Thanks,
        Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: CEDET sync

[Stefan Monnier]

> Problem is, I didn't see a clear and hassle-free path to do
> cross-project merging in the long term (I didn't ask the GNUS people
> about their strategy).

I don't know of any good answer either.

Maybe the best option is to make the upstream repository "track" the
Emacs repository; any change made in Emacs can be trivially merged back
into upstream.

Then every once in a while, someone syncs up the upstream with the Emacs
code (mainly overwriting the Emacs code with the upstream code, but
being careful to avoid race conditions where someone commits to the
Emacs repository between the last merge and the actual overwrite).


        Stefan

Re: CEDET sync

[Daniel Clemente]

>
> My concern with such a scheme is how (*) to transplant changes from cedet into
> an emacs subdirectory, such that all cedet commit logs and dates are maintained.
>

 An easier setup:

  The CEDET branch (where CEDET programmers make most changes) is a branch of Emacs' trunk (done by: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/ cedet).
  That means they don't work with „a directory which contains CEDET“, but with „a directory which contains the whole Emacs, including CEDET“. Obviously their changes will affect mostly the CEDET part and not the rest of Emacs.
  To bring changes by Emacs' trunk developers into the CEDET branch, use bzr pull (bzr merge if there were conflicts). It will be easy because both branches have a common ancestor.
  To push CEDET changes to Emacs' trunk, use bzr push. It will be as easy. You don't have to worry about putting things in the correct subdirectory because the file structure is the same in both branches.
  In order to package CEDET in a .tar.gz, care should be taken to select only the CEDET-related files and not the whole Emacs.

  This setup has the disadvantage of taking a little more space in disk for the CEDET branch (because you handle much more than CEDET), but other than that, it's very easy.


  Greetings,
Daniel

Re: CEDET sync

[Lluís]

>> 
>> My concern with such a scheme is how (*) to transplant changes from cedet into
>> an emacs subdirectory, such that all cedet commit logs and dates are maintained.
>> 

>  An easier setup:

>   The CEDET branch (where CEDET programmers make most changes) is a branch of
>   Emacs' trunk (done by: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/
>   cedet).
[...]
>   This setup has the disadvantage of taking a little more space in disk for
>   the CEDET branch (because you handle much more than CEDET), but other than
>   that, it's very easy.

This takes a whole lot more space to have local copies, and in the case of bzr
this translates into much slower operations.

Besides, there's people using other emacs' flavours.

What we ought to know is how to easily transplant changes and commit
information.

In order to make such merges look good in the log history (e.g., "merge from
cedet trunk"; such that not all cedet individual commit messages are visible in
the "top-level" commit messages), the cedet -> emacs merge should be something
like:

      * create new branch in emacs for the sole purpose of the merge
      * transplant changes maintaining author, log and date information
      * record in a file which revisions have been merged and/or discarded for
        merge (those not recorded will be candidate for merge in posterior runs
        of the script)
      * merge this branch wherever it fits
      * delete branch

I'm sure a simple script could be written to perform points 2 and 3 for each
revision, and another to show a log only with the revisions not listed in the
aforementioned file.

apa!

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth