[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Switching CEDET from CVS to a Distributed VCS.

From: Stephen J. Turnbull
Subject: Re: Switching CEDET from CVS to a Distributed VCS.
Date: Tue, 30 Jun 2009 08:19:54 +0900

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]