Hi everyone, noticed a furore on Slashdot yesterday over Bitmover dropping support for the free version of Bitkeeper. http://www.bitkeeper.com/press/2005-04-05.html You may hear the "I told you so''s" in the distance if you listen carefully :o) In the meantime, what will the wonderful Xen project leaders do? Regards, Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Paul Dorman wrote:> Hi everyone, > > noticed a furore on Slashdot yesterday over Bitmover dropping support > for the free version of Bitkeeper. > > http://www.bitkeeper.com/press/2005-04-05.html > > You may hear the "I told you so''s" in the distance if you listen > carefully :o)I have been tracking Xen with TLA/Arch ever since getting involved, and that has worked really fine for me. These days there is also the Ubuntu-sponsored Bazaar, which I think is mostly Arch-compatible, but with command line syntax closer to what BK and CVS users may expect. The only problem with Arch and Xen is that Arch really works best if your build-targets live in their own directory, rather being littered all over the source tree. It can be convinced to ignore all the unversioned stuff, but I think what usually happens is that Arch manages to convince its users to modify the build scripts (saves a lot of ''make clean && make''s too if you do it right and makes the source tree easier to navigate) rather than the other way around. The good news is that with all these great new tools coming out, tracking an upstream code base has become a lot simpler than it used to be, making it easier for users to run with whatever system they prefer. Personally, I''ll stick with TLA/Arch. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen wrote:> I have been tracking Xen with TLA/Arch ever since getting involved, > and that has worked really fine for me.Cool. I''m interested in tracking it with darcs, myself. I''m curious what process/scripts you''re using to do the tracking. Thanks -Tupshin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hTupshin Harper wrote:> Jacob Gorm Hansen wrote: > >> I have been tracking Xen with TLA/Arch ever since getting involved, >> and that has worked really fine for me. > > > Cool. I''m interested in tracking it with darcs, myself. I''m curious what > process/scripts you''re using to do the tracking.I did the initial import manually from a tarball, using ''tla add'' to add all files by hand (actually, I did ''tla tree-lint -t |xargs tla add'' repeatedly, until all dirs and files were added), and I use the following script to stay up to date: (My archive is called xen, branch is called ''unstable'', version is 3.0) ------------------------------------------ tla get xen--unstable--3.0 xen--unstable--3.0 ( cd xen--unstable--3.0 tla inventory -s | xargs rm -rf ) wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable-src.tgz tar xfz xen-unstable-src.tgz cp -ra xen-unstable/* xen--unstable--3.0 ------------------------------------------ I run the script in an empty directory, and it leaves me with a xen--unstable--3.0 checkout containing the upstream changes. I cd in there, and run tla tree-lint To see if there are any new, renamed* or deleted files that tla needs to know about. I then add, rename or delete as needed, and when tree-lint is happy I can ''tla commit''. I keep my own changes in a separate branch, called xen--whatever--3.0, and do all my work there. To replay upstream changes into my own branch, I use ''tla star-merge -t xen--unstable--3.0'', resolve any conflicts, and ''tla commit''. I have seen better automated approaches, but the method above works fine for me, leaves me in full control, and generally takes less than five minutes to complete. Jacob *) in case of a renamed directory, e.g. a new linux version number, I generally start over after having performed the directory-rename by hand in another checkout, as otherwise I will end up with multiple directories with the same content. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Apr 07, 2005 at 04:26:47PM -0700, Tupshin Harper wrote:> Jacob Gorm Hansen wrote: > > Cool. I''m interested in tracking it with darcs, myself. I''m curious what > process/scripts you''re using to do the tracking.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. sRp -- Scott Parish _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Apr 07, 2005 at 05:21:15PM -0700, Jacob Gorm Hansen wrote:> 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.darcs has been fast enough for xen; linux is a completely different story :) sRp -- Scott Parish _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
* Jacob Gorm Hansen (jacobg@diku.dk) wrote:> 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.It might be tough. That bk client doesn''t really give you a bk repo. It gives you a source tree and a file called ChangeLog, but no other metadata. So associating entries in ChangeLog with actual csets is best guess. You can pull a specific revision, so that plus a forest of cp -rl trees and diff -Naur is conceptually feasible. But I''m not sure how well it would preserve bk merges. thanks, -chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen wrote:> > 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.) >Haskell is a bit slower, but the real culprit is design related. The author and crew are working on it. Should be cleared up eventually. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sean Perry wrote:> Haskell is a bit slower, but the real culprit is design related. The > author and crew are working on it. Should be cleared up eventually.Hmm, the Wiki page about darcs performance looks rather scary: http://www.scannedinavian.org/DarcsWiki/Performance And quoting from the "Best Practices" page at http://www.scannedinavian.org/DarcsWiki/BestPractices : "Also, very large conflicts and complex conflicts can cause darcs to use an exponential amount of CPU power to solve the problem, giving the appearance that darcs is "spinning" or "hanging"" From what I have read about darcs, the problem is the ''theory of patches'' approach which demands that all patches be loaded into memory at once so that the order in which they should be applied can be determined via a n*n comparison of the contents of each patch against the contents of all other patches. While all this talk of quantum operators may sound sexy at first, I am fairly sure it is vastly overkill for real-world source-control. I other words, I would not be too optimistic about darcs having its performance issues cleared up in the shorter term. Besides, there is the issue of using a tool written in a language that the majority of programmers will find hard to understand*. Jacob * Not me of course, I was exposed to Miranda at an early age ;-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jacob Gorm Hansen wrote:> From what I have read about darcs, the problem is the ''theory of > patches'' approach which demands that all patches be loaded into memory > at once so that the order in which they should be applied can be > determined via a n*n comparison of the contents of each patch against > the contents of all other patches.I don''t know precisely why the current darcs implementation needs as much memory as it does, but I know it is not for the above reason. An important property of the ''theory of patches'' is that merges can be done in arbitrary order (see <http://abridgegame.org/darcs/manual/node8.html>). The size of a merged patch will be similar to the sum of the sizes of the input patches, just as in other SCSs. A very simple-minded implementation that literally reconstructs the whole repository by patching an empty one would require memory proportional to the repository size, but there''s nothing about the theory that would require you to handle the whole repository at once. > Hmm, the Wiki page about darcs performance looks rather scary: > > http://www.scannedinavian.org/DarcsWiki/Performance Those look like implementation nits to me, with known workarounds. Also remember that other SCSs only support what darcs calls ''hunk patches''. IIUC, it''s only if you use features of darcs that are not present in other SCSs that you hit the exponential complexity cases that are mentioned on the wiki page. That said, I''ve heard reports that the current darcs implementation can get a repository into states that require an understanding of its internals to get out of. It wouldn''t be the only SCS that has that property, but people may be more used to the particular ways in which CVS et al get confused.> While all this talk of quantum operators may sound sexy at first, I am > fairly sure it is vastly overkill for real-world source-control.<sigh>. From a marketing point of view, even mentioning quantum mechanics is a disaster. It might have been fine when the audience for darcs was three physicists, but that page really should be rewritten. Anyway, the limit of the analogy between QM and darcs'' theory of patches is that they both involve commutative operators; that''s all.> I other words, I would not be too optimistic about darcs having its > performance issues cleared up in the shorter term. Besides, there is the > issue of using a tool written in a language that the majority of > programmers will find hard to understand*.The majority of programmers would have difficulty in understanding an SCS implementation written in any language. Plenty of programmers understand Haskell. -- David Hopwood <david.nospam.hopwood@blueyonder.co.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel