Re: Switching CEDET from CVS to a Distributed VCS.

Re: Switching CEDET from CVS to a Distributed VCS.

[Lennart Borgman]

Hi Eric,

I think I have said it before, but I believe it is worth saying again:
Emacs repository will be moved from CVS to Bazaar. And since CEDET is
going to be included in Emacs you will most likely be using Bazaar
after that.

Alex, as I said before I do not know much at all about version control
system. However even from my limited understanding of this I still
can't find room for arguments for using something else than Bazaar for
CEDET. Will not using something else than Bazaar put an extra burdon
on Eric? And I guess that is what we all want to avoid ... ;-)

I am CC-ing Emacs Devel because there are people who understands this
much better than I do.



On Thu, Jun 25, 2009 at 12:22 AM, Eric M. Ludlam<eric@siege-engine.com> wrote:
> Hi all,
>
>  Alex Ott has been looking into what it would take to move CEDET from
> CVS to a distributed version control system, such as GIT or Mercurial.
> (Thanks Alex)
>
>  I haven't used these systems myself, but would be happy to learn in
> order to make access to CEDET easier.  Does anyone have advice on a good
> tactic to take?  Whatever it is needs to be low maintenance for me, as
> I'd rather spend my time hacking Emacs than dealing with VCSes.
>
>  Alex's high level summary is:
>
> ------------
> Mercurial (http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial)
> we'll have:
>  + Native support for all platforms - Unix/Windows
>  + Anonymous access to repository via http
>  - Less features out of box, comparing with Git, but most of them are
>  available as extensions, installed separately
>
> For Git (http://sourceforge.net/apps/trac/sourceforge/wiki/Git) we'll
> have:
>  - Native support for Unixes only, Windows port is slightly limited
>  - Anonymous access via git protocol - this could make some problems for
>  users behind firewalls
>
> all other features seem the same.
> ------------
>
> Thanks for any input.
> Eric
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

------------------------------------------------------------------------------
_______________________________________________
Cedet-devel mailing list
Cedet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: Switching CEDET from CVS to a Distributed VCS.

[Eric M. Ludlam]

Hi Lennart,

  Thanks for the reminder, as I had forgotten.  Anything that makes
maintaining the CEDET code in the Emacs repository and my own repository
easier will help to help work around the paperwork issues I have to deal
with.  That would indeed be a big boon for me.

  I hadn't acted on these suggestions in the past because my Linux
distro had been so old and I was too lazy to build whatever vcs was
suggested myself.  Now that I've upgraded, this is no longer an issue.

Thanks
Eric

On Thu, 2009-06-25 at 00:45 +0200, Lennart Borgman wrote:
> Hi Eric,
> 
> I think I have said it before, but I believe it is worth saying again:
> Emacs repository will be moved from CVS to Bazaar. And since CEDET is
> going to be included in Emacs you will most likely be using Bazaar
> after that.
> 
> Alex, as I said before I do not know much at all about version control
> system. However even from my limited understanding of this I still
> can't find room for arguments for using something else than Bazaar for
> CEDET. Will not using something else than Bazaar put an extra burdon
> on Eric? And I guess that is what we all want to avoid ... ;-)
> 
> I am CC-ing Emacs Devel because there are people who understands this
> much better than I do.
> 
> 
> 
> On Thu, Jun 25, 2009 at 12:22 AM, Eric M. Ludlam<eric@siege-engine.com> wrote:
> > Hi all,
> >
> >  Alex Ott has been looking into what it would take to move CEDET from
> > CVS to a distributed version control system, such as GIT or Mercurial.
> > (Thanks Alex)
> >
> >  I haven't used these systems myself, but would be happy to learn in
> > order to make access to CEDET easier.  Does anyone have advice on a good
> > tactic to take?  Whatever it is needs to be low maintenance for me, as
> > I'd rather spend my time hacking Emacs than dealing with VCSes.
> >
> >  Alex's high level summary is:
> >
> > ------------
> > Mercurial (http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial)
> > we'll have:
> >  + Native support for all platforms - Unix/Windows
> >  + Anonymous access to repository via http
> >  - Less features out of box, comparing with Git, but most of them are
> >  available as extensions, installed separately
> >
> > For Git (http://sourceforge.net/apps/trac/sourceforge/wiki/Git) we'll
> > have:
> >  - Native support for Unixes only, Windows port is slightly limited
> >  - Anonymous access via git protocol - this could make some problems for
> >  users behind firewalls
> >
> > all other features seem the same.
> > ------------
> >
> > Thanks for any input.
> > Eric
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Cedet-devel mailing list
> > Cedet-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/cedet-devel
> >

------------------------------------------------------------------------------

Re: Switching CEDET from CVS to a Distributed VCS.

[Miles Bader]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> Alex, as I said before I do not know much at all about version control
> system. However even from my limited understanding of this I still
> can't find room for arguments for using something else than Bazaar for
> CEDET. Will not using something else than Bazaar put an extra burdon
> on Eric?

Sure, although if say git were sufficiently better than bazaar, that
might be offset by a more pleasant time when actually developing the
project.  I personally use git locally even when upstream uses some
other VCS, simply because it's much, much, better than them, and the
annoyance of the extra syncing step is offset by far more facile
operation for the bulk of my development work (merging/syncing
consumes a relatively small proportion of my "VCS time").

[When emacs switches to bazaar, I'll probably try to find a git/bazaar
gateway so I can use git locally.]

Bazaar is, mostly likely, better than CVS however.

-Miles

-- 
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.

Re: Switching CEDET from CVS to a Distributed VCS.

[David Bernard]

[-- Attachment #1.1: Type: text/plain, Size: 2923 bytes --]

Hi,

If you choose git. I suggest to use http://github.com to host a "central"
version :
* provide documentation for newbee (step by step to create your project,...)
* an interesting feature :
** "committers" could easily work on branch
** non-committers could easily fork project in there own space and propose
patch/branch,...
* ...
Than using git or mercurial on sourceforge.

One year ago, I request the List project to move from subversion (hosted by
google) to DVCS (I used mercurial at work (choose by me 1.5 years ago)),
without success but after a discussion and an overview of github the lead
start learning git an move the project to github.

I use mercurial day to day at office and git/github for my oss project.
IMHO : the main difference are :
* mercurial works on Windows (easily)
* git manage named branches (at office we decided to use 2 mercurial
repositories to manage project (wip and release) instead of 2 branches,
because working with branches in mercurial is more error prone)

second level differences :
* git allow you to keep changes from an other repository without required
that your repository is full commited (no pending changes). mercurial need
extension to provide similar job
* git could compress/strip history

my 2cents (I'm not a CEDET nor emacs contributor)

note : on github, projects are not group by "projects" but by owner, eg: my
own http://github.com/davidB

On Thu, Jun 25, 2009 at 04:40, Miles Bader <miles@gnu.org> wrote:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
> > Alex, as I said before I do not know much at all about version control
> > system. However even from my limited understanding of this I still
> > can't find room for arguments for using something else than Bazaar for
> > CEDET. Will not using something else than Bazaar put an extra burdon
> > on Eric?
>
> Sure, although if say git were sufficiently better than bazaar, that
> might be offset by a more pleasant time when actually developing the
> project.  I personally use git locally even when upstream uses some
> other VCS, simply because it's much, much, better than them, and the
> annoyance of the extra syncing step is offset by far more facile
> operation for the bulk of my development work (merging/syncing
> consumes a relatively small proportion of my "VCS time").
>
> [When emacs switches to bazaar, I'll probably try to find a git/bazaar
> gateway so I can use git locally.]
>
> Bazaar is, mostly likely, better than CVS however.
>
> -Miles
>
> --
> Justice, n. A commodity which in a more or less adulterated condition the
> State sells to the citizen as a reward for his allegiance, taxes and
> personal
> service.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>

[-- Attachment #1.2: Type: text/html, Size: 3784 bytes --]

[-- Attachment #2: Type: text/plain, Size: 79 bytes --]

------------------------------------------------------------------------------

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Cedet-devel mailing list
Cedet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] Switching CEDET from CVS to a Distributed VCS.

[Davi Diaz]

David Bernard wrote:
> If you choose git. I suggest to use http://github.com to host
> a "central" version:

Savannah is a lot quicker than github.

  http://savannah.gnu.org/

And Savannah is here to support Free Software. It is not a business as 
github.com is. See http://github.com/plans

Of course Emacs is at Savannah.

Re: [CEDET-devel] Switching CEDET from CVS to a Distributed VCS.

[Miles Bader]

Davi Diaz <davi@leals.com> writes:
>> If you choose git. I suggest to use http://github.com to host
>> a "central" version:
>
> Savannah is a lot quicker than github.
>
>   http://savannah.gnu.org/
>
> And Savannah is here to support Free Software. It is not a business as 
> github.com is. See http://github.com/plans

Github is a decent site (tho I dislike their super-glossy-but-flaky UI)
for small projects, but I get more warm fuzzies from being on savannah,
and feel a bit more confident that savannah will be around in the
future.

The initial application to savannah is more involved, and you need to
meet their requirements (CEDET almost certainly does, of course), but
everything works quite well after that.

I think being on savannah also lends more of an "official" air.  If I
see a download is from savannah -- even if it's on nongnu -- it adds a
degree of trust.  At the least, I know the source code was vetted to
_some_ degree before the initial upload.

-Miles

-- 
Opportunity, n. A favorable occasion for grasping a disappointment.

Re: Switching CEDET from CVS to a Distributed VCS.

[Stephen J. Turnbull]

Miles Bader writes:

 > Bazaar is, mostly likely, better than CVS however.

I believe Bazaar now supports fastimport format in both directions.

Interaction between git and Bazaar probably means you lose/munge
VCS-specific metadata (Bazaar cares about revision numbers while git
doesn't support them at all, and the revision ID formats are
timestamp-specific in each VCS, so converting those in a
roundtrippable way would require great care) in each direction, but
with minimal care you should be able to preserve the history dag and
core meta data (author information).

Re: Switching CEDET from CVS to a Distributed VCS.

[David Reitter]

On Jun 25, 2009, at 1:48 PM, Stephen J. Turnbull wrote:
> I believe Bazaar now supports fastimport format in both directions.
>
> Interaction between git and Bazaar probably means you lose/munge
> VCS-specific metadata (Bazaar cares about revision numbers while git
> doesn't support them at all, and the revision ID formats are
> timestamp-specific in each VCS, so converting those in a
> roundtrippable way would require great care) in each direction, but
> with minimal care you should be able to preserve the history dag and
> core meta data (author information).

fast-import (bzr->git at least) keeps an index to facilitate fast  
incremental exports.
Suppose one has a commit in the git repo to be committed to the Bzr  
repo, would it be possible to

1. convert a git patch (git-format-patch) to a Bazaar merge directive?
2. use fast-import/export to export just the patch?

Re: Switching CEDET from CVS to a Distributed VCS.

[Stephen J. Turnbull]

David Reitter writes:
 > On Jun 25, 2009, at 1:48 PM, Stephen J. Turnbull wrote:
 > > I believe Bazaar now supports fastimport format in both directions.
 > >
 > > Interaction between git and Bazaar probably means you lose/munge
 > > VCS-specific metadata (Bazaar cares about revision numbers while git
 > > doesn't support them at all, and the revision ID formats are
 > > timestamp-specific in each VCS, so converting those in a
 > > roundtrippable way would require great care) in each direction, but
 > > with minimal care you should be able to preserve the history dag and
 > > core meta data (author information).
 > 
 > fast-import (bzr->git at least) keeps an index to facilitate fast  
 > incremental exports.
 > Suppose one has a commit in the git repo to be committed to the Bzr  
 > repo, would it be possible to
 > 
 > 1. convert a git patch (git-format-patch) to a Bazaar merge directive?

This is software, anything's possible.  Useful?  Probably not.  I
don't see why you'd want to do anything other than maintain pairs of
bzr-git bidi mirrored branches.  In particular, merge directives are
most useful if you have a formal review process and a patch queue
manager such as Bundle Buggy or PQM.  That's just so not Emacs.  Emacs
has committers, not reviewers.  Maybe CEDET has a more formal process,
but you still wouldn't want to use merge directives without automatic
help AFAICS.

 > 2. use fast-import/export to export just the patch?

I really don't see why you'd want to do this.  "Just patches" makes
a lot of sense if your name is Andrew Morton.  (Not necessarily
literally, but someone whose mission in life is managing such a
patch-based workflow.)

Agreed, compared to ideal, or even to git, bzr's performance sucks,
even after a 500% or so speed up in certain operations.  But
realistically, it's usable, unless you want to hang `(shell-command
"$VCS commit -a -m autocommit;$VCS log -10")' on your save-buffer-hook
as I do.

What bzr cannot do very well that git excels at is editing history.
bzr is a FORTRAN derivative.  For all practical purposes, unless
you're a bzr.dev, history is a linear array in each branch.  Unless
you really really know what you're doing, you don't want to do
anything but work linearly in each branch, and occasionally merge to
mainline.  But guess what?  Most people just want to work linearly in
each branch, and occasionally merge to mainline.  I see no problem
here, do you?

git is a LISP derivative.  If you are comfortable with cons, setcdr,
and mapcar, then you will be comfortable with git-commit, git-rebase,
and git-filter-branch.  And you will feel the power.  But hey, every
minute you spend playing with git is a minute you're not hacking
Emacs.  Is it worth it?

Seriously, if you're a git aficianado, set up the bidirectional
mirror, create a pushthrough script that pushes from the git repo to
the local bzr repo, and on from the local bzr repo to Emacs Central,
and (my best guess) be happy.  If you then find you're not happy yet,
*then* it's time to discuss these optimizations.  Both git and bzr are
flexible enough that you can be confident of finding ways to
streamline later if it's necessary.

Re: Switching CEDET from CVS to a Distributed VCS.

[David Reitter]

On Jun 28, 2009, at 2:17 AM, Stephen J. Turnbull wrote:

>> 1. convert a git patch (git-format-patch) to a Bazaar merge  
>> directive?
>
> This is software, anything's possible.

I looked into it and it's fairly easy to do.  It would be for local  
use rather than for review by e-mail.

>  Useful?  Probably not.  I
> don't see why you'd want to do anything other than maintain pairs of
> bzr-git bidi mirrored branches.

> Seriously, if you're a git aficianado, set up the bidirectional
> mirror, create a pushthrough script that pushes from the git repo to
> the local bzr repo, and on from the local bzr repo to Emacs Central,
> and (my best guess) be happy.

This would be the ideal case and very, very convenient.  I hope there  
will be such a mirror [on savannah if possible], but I'm not sure how  
it would handle merge failures, assuming that this sync script runs  
periodically and without user intervention.  The more frequently the  
git mirror is updated, the less likely it is that a git->bzr merge  
fails.   If it does fail, I'm not sure how to handle it well.  That's  
why I didn't pursue the idea so far.

Re: Switching CEDET from CVS to a Distributed VCS.

[Stephen J. Turnbull]

David Reitter writes:
 > On Jun 28, 2009, at 2:17 AM, Stephen J. Turnbull wrote:
 > 
 > >> 1. convert a git patch (git-format-patch) to a Bazaar merge  
 > >> directive?
 > >
 > > This is software, anything's possible.
 > 
 > I looked into it and it's fairly easy to do.  It would be for local  
 > use rather than for review by e-mail.

Instead of parsing the patch and/or log for meta data, applying the
patch and committing with "bzr commit"?  That's creative.  Good idea,
and good luck with it, it deserves a try.

 > > Useful?  Probably not.

OK, I retract that.<wink>

 > > Seriously, if you're a git aficianado, set up the bidirectional
 > > mirror, create a pushthrough script that pushes from the git repo to
 > > the local bzr repo, and on from the local bzr repo to Emacs Central,
 > > and (my best guess) be happy.
 > 
 > This would be the ideal case and very, very convenient.  I hope there  
 > will be such a mirror [on savannah if possible],

This would be an amazing time sink for the Savannah people, is my
guess.  Not a good idea -- a lot of people would use it and conflicts
would be frequent, I think.  The extra bzr repos will stay way under
1GiB for the forseeable future, it's just not a big deal to keep them
locally.  Savannah should maintain the official format, period.

In theory you could use incremental fastimport format as a wire
protocol, but I wouldn't want to try that without core support from
the bzr devs.  Given how much effort they put into protocol and format
proliferation, I doubt they'd be happy to restrict themselves to a
simple NIH protocol.

 > but I'm not sure how it would handle merge failures, assuming that
 > this sync script runs periodically and without user intervention.

If it runs locally on your box while you're not working, it should
rarely have bad conflicts, and you should be able to resolve them
manually without trouble.  

 > The more frequently the git mirror is updated, the less likely it
 > is that a git->bzr merge fails.  If it does fail, I'm not sure how
 > to handle it well.  That's why I didn't pursue the idea so far.

The git->bzr pushthrough script would try to do a bzr->git merge
first, of course.  You want *all* failures to happen in your local git
repository because that's where you want to deal with amending commits
and similar history manipulations.  If that doesn't excite you, learn
to use bzr.  Trying to maintain bidirectional synchronization is going
to drive somebody crazy.

Re: Switching CEDET from CVS to a Distributed VCS.

[David Reitter]

On Jun 28, 2009, at 10:04 AM, Stephen J. Turnbull wrote:

> Instead of parsing the patch and/or log for meta data, applying the
> patch and committing with "bzr commit"?  That's creative.  Good idea,
> and good luck with it, it deserves a try.

git-mailinfo exposes the functions to parse a patch into commit  
message and patch.
You get the usual meta data as well.

> This would be an amazing time sink for the Savannah people, is my
> guess.  Not a good idea -- a lot of people would use it and conflicts
> would be frequent, I think.

Point well taken.  Still, Savannah already has an excellent git mirror.

> In theory you could use incremental fastimport format as a wire
> protocol, but I wouldn't want to try that without core support from
> the bzr devs.

Yes.   Just worried about automatically creating and pushing very bad  
revisions.
>
> The git->bzr pushthrough script would try to do a bzr->git merge
> first, of course.

I was hoping that all that will remain outsourced, as it is now.  I've  
had plenty of bad experiences with importing (CVS mostly) into bzr;   
perhaps the route bzr->git is easier, but a working and safe two-way  
sync.. . Like you say:

> Trying to maintain bidirectional synchronization is going
> to drive somebody crazy.

For this reason I was wondering if the patch-bundle route would be a  
clean way to push stuff to bzr. 

Re: Switching CEDET from CVS to a Distributed VCS.

[Stephen J. Turnbull]

David Reitter writes:
 > On Jun 28, 2009, at 10:04 AM, Stephen J. Turnbull wrote:

 > > This would be an amazing time sink for the Savannah people, is my
 > > guess.  Not a good idea -- a lot of people would use it and conflicts
 > > would be frequent, I think.
 > 
 > Point well taken.  Still, Savannah already has an excellent git mirror.

I suppose they could keep it running pretty cheaply.  IMO it's mission
creep, and Savannah doesn't need mission creep, they have enough
trouble just staying up.

 > I was hoping that all that will remain outsourced, as it is now.  I've
 > had plenty of bad experiences with importing (CVS mostly) into bzr;

Simply importing CVS is horrible because commits are non-atomic and
lack much necessary metadata to reconstruct commits and branching
events reliably.  Experience with CVS doesn't even extrapolate to SVN,
let alone bzr, git, and hg.

 > > Trying to maintain bidirectional synchronization is going
 > > to drive somebody crazy.
 > 
 > For this reason I was wondering if the patch-bundle route would be a  
 > clean way to push stuff to bzr. 

No.  Why do you think it would be any better than anything else?  Once
you've got atomic commits, the rest of the issues are "what metadata
does your VCS record?" which are pretty similar for the VCSes under
consideration, and genuine conflicts, which have to be resolved
somewhere.  VCSes aren't magic; when you and I make different changes
to the same line of code, some human has to sort that out.

The problem with bidirectional mirrors is that humans are "supposed"
to be out of the loop at the point where genuine conflict occurs.
Unidirectional mirrors don't face this problem, and with a local bidi
mirror, responsibility for the problem is clear and equal to the
person who will experience damage/inconvenience.

Re: Switching CEDET from CVS to a Distributed VCS.

[David Reitter]

On Jun 29, 2009, at 7:19 PM, Stephen J. Turnbull wrote:

>> For this reason I was wondering if the patch-bundle route would be a
>> clean way to push stuff to bzr.
>
> No.  Why do you think it would be any better than anything else?  Once
> you've got atomic commits, the rest of the issues are "what metadata
> does your VCS record?" which are pretty similar for the VCSes under
> consideration, and genuine conflicts, which have to be resolved
> somewhere.  VCSes aren't magic; when you and I make different changes
> to the same line of code, some human has to sort that out.
>
> The problem with bidirectional mirrors is that humans are "supposed"
> to be out of the loop at the point where genuine conflict occurs.
> Unidirectional mirrors don't face this problem, and with a local bidi
> mirror, responsibility for the problem is clear and equal to the
> person who will experience damage/inconvenience.

Well, that's precisely why I suggested the patch-bundle method in the  
first place - it would be local.

I would probably implement a script that does this, if someone else  
provides a working (read-only) git mirror of the bzr repository.

Re: [CEDET-devel] Switching CEDET from CVS to a Distributed VCS.

[Lennart Borgman]

On Thu, Jun 25, 2009 at 5:23 AM, David Reitter<david.reitter@gmail.com> wrote:
> On Jun 24, 2009, at 6:45 PM, Lennart Borgman wrote:
>
>> Hi Eric,
>>
>> I think I have said it before, but I believe it is worth saying again:
>> Emacs repository will be moved from CVS to Bazaar. And since CEDET is
>> going to be included in Emacs you will most likely be using Bazaar
>> after that.
>>
>> Alex, as I said before I do not know much at all about version control
>> system. However even from my limited understanding of this I still
>> can't find room for arguments for using something else than Bazaar for
>> CEDET. Will not using something else than Bazaar put an extra burdon
>> on Eric? And I guess that is what we all want to avoid ... ;-)
>
> If it helps others over at Cedet:
>
> I evaluated Bazaar over the course of 6 months for Aquamacs (which
> incorporates the full Emacs repository).  Using Bazaar with this repository
> (and coming up with a workable conversion of Aquamacs and Emacs CVSes) was
> endless pain, frustration and bug reporting (starting with cryptic error
> messages from the bowels of Bzr).
>
> Bzr is well-meant and its UI is well-designed, but it lacks the efficiency
> and reliability to manage a repository with >100k revisions.   It lacks a
> quality assurance process (with its monthly release cycle that's difficult)
> and reliable error signaling / integrity checking (its ever-changing
> repository formats are not seamless at all w.r.t. transitions).  It is
> dog-slow with a large repository, even with the latest changes to "bzr log".



Thanks David, hope you do not mind I am sending this along to Emacs Devel.

Are these problems still there? In that case they might be very
important for the time scale when switching Emacs to using Bazaar.



> Git has been painless and elegant.   Nothing gets in your way.
>
> All that said, I tried very hard to make Bzr work for us and spent a lot of
> time dealing with bugs, precisely for the reasons that Lennart stated.
>
> For a smaller repository, Bzr may well work, especially if you don't import
> a "messed up" CVS repo with many branches.
>
> (Otherwise, it seems that a lot of Emacs dev's use Git to manage their work
> privately before transferring their changes into the Emacs repository.)

Re: [CEDET-devel] Switching CEDET from CVS to a Distributed VCS.

[Stefan Monnier]

> Are these problems still there? In that case they might be very
> important for the time scale when switching Emacs to using Bazaar.

Please just stop this discussion.  The only useful thing to do at this
point is to help move from CVS to Bazaar.


        Stefan

Re: [CEDET-devel] Switching CEDET from CVS to a Distributed VCS.

[David Reitter]

On Jun 25, 2009, at 4:44 AM, Lennart Borgman wrote:

> Thanks David, hope you do not mind I am sending this along to Emacs  
> Devel.
>
> Are these problems still there? In that case they might be very
> important for the time scale when switching Emacs to using Bazaar.

Please disregard my forwarded message.  It was intended to be private.

While I have a technical opinion as a result from evaluating the  
software, I would be the last one to voice it publicly in this way  
when it could discourage developers of a free, well-intentioned,  
commendable effort like Bazaar, who have shown friendly responsiveness  
and professionalism on their mailing list in the past.  Let's be  
outspoken in private and/or whenever it serves a purpose.

The decision for Emacs has been made and other, related projects and  
developers may now either live with it or work around it (see also  
Miles' message).  In fact if there are some fellow Git users, perhaps  
one could exchange Git/Bzr integration strategies by e-mail.  Drop me  
a line and I will bring people together to coordinate.