From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: Bitkeeper Date: Thu, 07 Apr 2005 17:21:15 -0700 Message-ID: <4255CE7B.8050300@diku.dk> References: <1112911404.7186.75.camel@localhost.localdomain> <4255B1B7.2030403@diku.dk> <4255C1B7.6050509@tupshin.com> <20050407235521.GC29680@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050407235521.GC29680@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Scott Parish Cc: Xen-devel@lists.xensource.com, Tupshin Harper List-Id: xen-devel@lists.xenproject.org Scott Parish wrote: > On Thu, Apr 07, 2005 at 04:26:47PM -0700, Tupshin Harper wrote: > > cd ~/darcs/BK-xen-unstable > ~/bin/bk_client-1.1/update bk://xen.bkbits.net/xeno-unstable.bk > darcs add -r * > darcs record -am "merge with bk://xen.bkbits.net/xeno-unstable.bk" > > I keep BK-xen-unstable as a clean mirror, updated daily. For dev > work i branch off that, and stay in sync using "darcs pull". > Unfortunately, this isn't granular to individual bk patches, and > renames show up as del/adds. The advantage to the more manual approach is that you can track renames, but you can probably do that with darcs as well. From what I have heard, the main problem with darcs is that is uses lots of memory when operating on big trees, and that it is a bit slow due to having been written in Haskell. It does seem simpler to use than TLA/Arch however, but Bazaar tries to address that (though I don't think this is an issue once you get used to TLA.) With the recently announced open source bk client I suppose one could create a script that would automatically track bk changes on a per-changeset basis, including renames. Jacob