Is anyone else having difficulty pulling from the Testing repository? Since last night my connection has been timing out, and attempts to browse http://xen.bkbits.net/ have timed out as well (as has www.bkbits.net) Regards, Jim Greer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jim Greer wrote:> Is anyone else having difficulty pulling from the Testing repository? > Since last night my connection has been timing out, and attempts to > browse http://xen.bkbits.net/ have timed out as well (as has > www.bkbits.net) >I''m having the same problem here. Jun> Regards, > Jim Greer > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[cc''ed to the list because it might be of interest]> We''re currently investigating alternatives to BK for the public repos > and should have an alternative up and running in a couple of weeks.Is there a plan for moving away from BK? Looks like git is going to be used for Linux but since our codebase is much smaller, I''d think we could find something more friendly without it having the same performance issues... Cheers, Mark> You can always pull the nightly src tar ball. > > Cheers, > Ian > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Is anyone else having difficulty pulling from the Testing repository? > Since last night my connection has been timing out, and > attempts to browse http://xen.bkbits.net/ have timed out as > well (as has > www.bkbits.net)Looks like bkbits is down, again. We''re currently investigating alternatives to BK for the public repos and should have an alternative up and running in a couple of weeks. You can always pull the nightly src tar ball. Cheers, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 21 May 2005, Mark Williamson wrote:> Is there a plan for moving away from BK? Looks like git is going to be used > for Linux but since our codebase is much smaller, I''d think we could find > something more friendly without it having the same performance issues...Mercurial is looking pretty promising, as is Monotone. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/21/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > > Is anyone else having difficulty pulling from the Testing repository? > > Since last night my connection has been timing out, and > > attempts to browse http://xen.bkbits.net/ have timed out as > > well (as has > > www.bkbits.net) > > Looks like bkbits is down, again. > > We''re currently investigating alternatives to BK for the public repos > and should have an alternative up and running in a couple of weeks.Yes, moving away from BK is definitely a good news for Xen ;-) regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 21 May 2005, Ian Pratt wrote:> We''re currently investigating alternatives to BK for the public repos > and should have an alternative up and running in a couple of weeks.Git? I am not sure I can recommend Arch any more after my experience with it as the linuxbios repo. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On Sat, 21 May 2005, Ian Pratt wrote: > > We''re currently investigating alternatives to BK for the > public repos > > and should have an alternative up and running in a couple of weeks. > > Git? > > I am not sure I can recommend Arch any more after my > experience with it as the linuxbios repo.That''s useful information, thanks. cogito (the renamed git) looks pretty ''raw'' at the moment. I did of playing around with mercurial last night and was impressed with how much functionality it has in just 2k lines of python. One option is to just have a public CVS repo, and then everyone can use whatever SCM tool they prefer as pretty much everything has an ''import from CVS'' feature. The only dowsnide to this is CVS''s inability to represent the current branch structure. BK''s algorithm for slecting the main branch is very ''odd'' indeed, and as it stands we''d loose a great deal of the revision history. I reckon we could do a much better job of linearizing the history (possibly with a bit of manual intervention). Can anyone think of a way of getting bitkeeper to output the revision DAG in a parseable form? Having this would also make it possible to keep the branch structure while transfering to a tool like mercurial or cogito. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/23/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > > On Sat, 21 May 2005, Ian Pratt wrote: > > > We''re currently investigating alternatives to BK for the > > public repos > > > and should have an alternative up and running in a couple of weeks. > > > > Git? > > > > I am not sure I can recommend Arch any more after my > > experience with it as the linuxbios repo. > > That''s useful information, thanks. > > cogito (the renamed git) looks pretty ''raw'' at the moment. I did of > playing around with mercurial last night and was impressed with how much > functionality it has in just 2k lines of python. > > One option is to just have a public CVS repo, and then everyone can use > whatever SCM tool they prefer as pretty much everything has an ''import > from CVS'' feature. The only dowsnide to this is CVS''s inability to > represent the current branch structure. >how about using subversion instead of CVS? one drawback of using Mercurial is that it is not that stable. as far as i know, nobody is using it now (?). so it is pretty risky to use Mercurial as a long term solution for Xen. regards, aq _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > cogito (the renamed git) looks pretty ''raw'' at the moment. I did of > > playing around with mercurial last night and was impressed with how > > much functionality it has in just 2k lines of python. > > > > One option is to just have a public CVS repo, and then everyone can > > use whatever SCM tool they prefer as pretty much everything has an > > ''import from CVS'' feature. The only dowsnide to this is CVS''s > > inability to represent the current branch structure. > > > how about using subversion instead of CVS?If we go down this interim route I think I''d rather have plain CVS as the ''lingua franca''.> one drawback of using Mercurial is that it is not that > stable. as far as i know, nobody is using it now (?). so it > is pretty risky to use Mercurial as a long term solution for Xen.I''m wasn''t proposing it as the soloution, I just see it as one of the most promising candidates for the future. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, May 21, 2005 at 08:52:53PM +0100, Mark Williamson wrote:> Is there a plan for moving away from BK? Looks like git is going to be used > for Linux but since our codebase is much smaller, I''d think we could find > something more friendly without it having the same performance issues...git is not only about performance, but also reliability. that''s why there''s no fancy merge algorithm (yet) and each revisions got a full file instead of a delta (although some people are working on adding delta support) -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> BK''s algorithm for slecting the main branch is very ''odd'' indeed, and as > it stands we''d loose a great deal of the revision history. I reckon we > could do a much better job of linearizing the history (possibly with a > bit of manual intervention).I''m not really familiar with bitkeeper or this pick-your-patches style of management/merging. Is there useful documentation outside of the bigkeeper user guide? (googling bitkeeper gives two pages of bitkeeper vs linux/open source hits)> Can anyone think of a way of getting > bitkeeper to output the revision DAG in a parseable form? Having this > would also make it possible to keep the branch structure while > transfering to a tool like mercurial or cogito.I''m not sure what DAG is, but I read a lkml posting from Linus that stated he had scripted a method of dumping data from BitKeeper, but hadn''t used it because he expected it to take days to complete(to pull the kernel source tree). -- Andrew Thompson http://aktzero.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 23 May 2005, aq wrote:> how about using subversion instead of CVS?subversion has been working very well for the openib community. I''ve been pretty happy with it. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, May 23, 2005 at 08:47:34AM +0100, Ian Pratt wrote:> cogito (the renamed git) looks pretty ''raw'' at the moment. I did of > playing around with mercurial last night and was impressed with how much > functionality it has in just 2k lines of python.I''m impressed with mercurial''s functionality and compactness too. At this point, the developers seem to be more interested in getting the core functionality right as opposed to getting the UI right (hg history shows history in chronological as opposed to reverse chronological order for eg).> One option is to just have a public CVS repo, and then everyone can use > whatever SCM tool they prefer as pretty much everything has an ''import > from CVS'' feature. The only dowsnide to this is CVS''s inability to > represent the current branch structure.I think there are multiple problems here: a) How to represent the current bk info without losing information until we solve (b) below? b) How to transistion to a different source control system that a large percentage of the devel community uses? c) How do read-mostly users get their updates? I''m thinking the answers are: a) mercurial b) None yet. c) CVS -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:> One option is to just have a public CVS repo, and then everyone can use > whatever SCM tool they prefer as pretty much everything has an ''import > from CVS'' feature. The only dowsnide to this is CVS''s inability to > represent the current branch structure.Whatever you choose, please make sure it is able to track renames (CVS is not). Again, I like Arch, but apparently not everyone does. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2005-05-23 at 10:11 +0100, Ian Pratt wrote:> > > cogito (the renamed git) looks pretty ''raw'' at the moment. I did of > > > playing around with mercurial last night and was impressed with how > > > much functionality it has in just 2k lines of python. > > > > > > One option is to just have a public CVS repo, and then everyone can > > > use whatever SCM tool they prefer as pretty much everything has an > > > ''import from CVS'' feature. The only dowsnide to this is CVS''s > > > inability to represent the current branch structure. > > > > > how about using subversion instead of CVS? > > If we go down this interim route I think I''d rather have plain CVS as > the ''lingua franca''.One thing I don''t particularly like about cvs is that it only tracks file changes rather than having a notion of a changeset. There are some obvious disadvantages with this such as with changes that affect more than one file (as most do), and ordering and such, but I have another. When I find a regression without an obvious cause, it''s often helpful to do a binary search through the changesets between the current and last-known working version to efficiently find out where it broke. This has been valuable for finding the source of both bugs and perf regressions in the kernel before. This is really hard to do with cvs. I''ve looked at cogito some and like it, I know it will let us do this. I don''t know about mercurial, I haven''t looked at it other than the couple of emails I had seen out on lkml announcing it. I didn''t think anyone was using it. -- Thanks, Paul Larson plars@linuxtestproject.org http://www.linuxtestproject.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
If you want lingua franca, go subversion. It is widely used now and supports the concept of a changeset. Commmits are atomic. CVS is just a toy. ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5/24/05, Arun Sharma <arun.sharma@intel.com> wrote:> c) How do read-mostly users get their updates?> c) CVSActually I think subversion is the better option. Basically a modern version of cvs, but particularly it tracks directory MACs in revision changesets. Something like this might be useful in the future if people prefer different version control systems. http://www.darcs.net/DarcsWiki/Tailor Nicholas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nicholas Lee wrote:> On 5/24/05, Arun Sharma <arun.sharma@intel.com> wrote: > >>c) How do read-mostly users get their updates? > > >>c) CVS > > > Actually I think subversion is the better option. Basically a modern > version of cvs, but particularly it tracks directory MACs in revision > changesets.Personally, I''d be very happy if we use svn-1.x as a "better CVS". I suggested CVS mainly because it''s more widely deployed and understood (although svn is increasingly taking over this space). Why would a read-mostly user need atomic commits? For changesets, something like mercurial would give more information, because it''s able to represent branches and merges better. -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Arun> Why would a read-mostly user need atomic commits? For Arun> changesets, something like mercurial would give more Arun> information, because it''s able to represent branches and Arun> merges better. Atomic commits are extremely useful for read-mostly users -- with per-file versioning as in CVS, it becomes very difficult to do a binary search to find out which changeset introduced a problem. With subversion, it''s quite easy for a tester to do this and be able to say "r1234 worked for me, r1235 crashes." - R. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 25 May 2005, Roland Dreier wrote:> Atomic commits are extremely useful for read-mostly users -- with > per-file versioning as in CVS, it becomes very difficult to do a binary > search to find out which changeset introduced a problem. With > subversion, it''s quite easy for a tester to do this and be able to say > "r1234 worked for me, r1235 crashes."Hi roland, did not know you were here. Yes, the atomic commit has been a lifesaver on openib! ron _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel