Xen repository

Xen repository

[Jim Greer]

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

RE: Xen repository

[Nakajima, Jun]

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

Re: Xen repository

[Mark Williamson]

[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

RE: Xen repository

[Ian Pratt]

> 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

Re: Xen repository

[Rik van Riel]

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

Re: Xen repository

[aq]

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

RE: Xen repository

[Ronald G. Minnich]

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

RE: Xen repository

[Ian Pratt]

 
> 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

Re: Xen repository

[aq]

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

RE: Xen repository

[Ian Pratt]

 
> > 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

Re: Xen repository

[Vincent Hanquez]

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

Re: Xen repository

[Andrew Thompson]

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/

Re: Xen repository

[Ronald G. Minnich]

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

Re: Xen repository

[Arun Sharma]

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

Re: Xen repository

[Jacob Gorm Hansen]

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

RE: Xen repository

[Paul Larson]

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

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Xen repository

[Ronald G. Minnich]

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

Re: Xen repository

[Nicholas Lee]

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.

Something like this might be useful in the future if people prefer
different version control systems. 
http://www.darcs.net/DarcsWiki/Tailor


Nicholas

Re: Xen repository

[Arun Sharma]

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

Re: Xen repository

[Roland Dreier]

    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.

Re: Xen repository

[Ronald G. Minnich]

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