* CEDET sync [not found] ` <87ocfsvxrl.fsf@stupidchicken.com> @ 2010-06-04 13:07 ` Stefan Monnier 2010-06-04 18:47 ` Eric M. Ludlam 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2010-06-04 13:07 UTC (permalink / raw) To: Eric Ludlam; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CEDET sync 2010-06-04 13:07 ` CEDET sync Stefan Monnier @ 2010-06-04 18:47 ` Eric M. Ludlam 2010-06-04 19:53 ` Lluís 0 siblings, 1 reply; 6+ messages in thread From: Eric M. Ludlam @ 2010-06-04 18:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eric Ludlam, emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CEDET sync 2010-06-04 18:47 ` Eric M. Ludlam @ 2010-06-04 19:53 ` Lluís 2010-06-04 20:53 ` Stefan Monnier 2010-06-06 6:34 ` Daniel Clemente 0 siblings, 2 replies; 6+ messages in thread From: Lluís @ 2010-06-04 19:53 UTC (permalink / raw) To: Eric M. Ludlam; +Cc: Stefan Monnier, emacs-devel >>> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CEDET sync 2010-06-04 19:53 ` Lluís @ 2010-06-04 20:53 ` Stefan Monnier 2010-06-06 6:34 ` Daniel Clemente 1 sibling, 0 replies; 6+ messages in thread From: Stefan Monnier @ 2010-06-04 20:53 UTC (permalink / raw) To: Lluís; +Cc: emacs-devel, Eric M. Ludlam > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CEDET sync 2010-06-04 19:53 ` Lluís 2010-06-04 20:53 ` Stefan Monnier @ 2010-06-06 6:34 ` Daniel Clemente 2010-06-06 13:21 ` Lluís 1 sibling, 1 reply; 6+ messages in thread From: Daniel Clemente @ 2010-06-06 6:34 UTC (permalink / raw) To: emacs-devel > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CEDET sync 2010-06-06 6:34 ` Daniel Clemente @ 2010-06-06 13:21 ` Lluís 0 siblings, 0 replies; 6+ messages in thread From: Lluís @ 2010-06-06 13:21 UTC (permalink / raw) To: Daniel Clemente; +Cc: emacs-devel >> >> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-06-06 13:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20100603153729.GD2763@loria.fr> [not found] ` <87ocfsvxrl.fsf@stupidchicken.com> 2010-06-04 13:07 ` CEDET sync Stefan Monnier 2010-06-04 18:47 ` Eric M. Ludlam 2010-06-04 19:53 ` Lluís 2010-06-04 20:53 ` Stefan Monnier 2010-06-06 6:34 ` Daniel Clemente 2010-06-06 13:21 ` Lluís
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).