On Sun, Aug 20, 2000 at 12:14:05PM +, Nik Clayton wrote:
> On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> > Summary: -current will be destabilized for an extended period (on the order
> > of months). A tag (not a branch) will be laid down before the initial
> > checkin, and no
Nik Clayton wrote:
> On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> > Summary: -current will be destabilized for an extended period (on the order
> > of months). A tag (not a branch) will be laid down before the initial
> > checkin, and non-developers should either stick closely t
On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
> Summary: -current will be destabilized for an extended period (on the order
> of months). A tag (not a branch) will be laid down before the initial
> checkin, and non-developers should either stick closely to that tag until
> the kern
On Thu, 22 Jun 2000, Greg Lehey wrote:
> On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
> >
> >> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> >>>
> >>> Ok, I have put up a web page that will track my efforts.
> >>>
> >>> http://apollo.backplane.com/
"Daniel C. Sobral" wrote:
> "Jordan K. Hubbard" wrote:
> >
> > Everyone talks about using bitkeeper but none of the people who
> > recommend it have ever actually tried to use it for anything.
> > Before such recommendations will bear weight, this needs to
> > change. :)
>
> OCVS? (Or was it OVC
> Using a non opensource commercial version control system is just
> to ask for bad carma, extended murphy fields and whatnot in an
> opensource volounteer project...
I would like to understand the discussed weakness of cvs regarding
branches.
Could someone explain it (in private) or point me to
On Wed, 21 Jun 2000, Chuck Robey wrote:
>On Wed, 21 Jun 2000, Mark Murray wrote:
>
>> >Has anyone given any thought to what it would take to create an
>> > open source version of something similar to perforce? ;-)
>>
>> Clearly you have. :-). We await your submissions with baited breath...
On Thu, Jun 22, 2000 at 01:56:56PM -0700, Greg Lehey wrote:
> On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
> >
> >> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> >>>
> >>> Ok, I have put up a web page that will track my efforts.
> >>>
> >>> http://ap
"Jordan K. Hubbard" wrote:
>
> Everyone talks about using bitkeeper but none of the people who
> recommend it have ever actually tried to use it for anything.
> Before such recommendations will bear weight, this needs to
> change. :)
OCVS? (Or was it OVCS? I can never recall...)
--
Daniel C. S
On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
>
>> On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
>>>
>>> Ok, I have put up a web page that will track my efforts.
>>>
>>> http://apollo.backplane.com/FreeBSDSmp/
>>
>> Your first patchset contains only i
:On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
:>
:> Ok, I have put up a web page that will track my efforts.
:>
:> http://apollo.backplane.com/FreeBSDSmp/
:
:Your first patchset contains only i386 code.
:What is the timeframe for alpha relative to i386?
:Will each i3
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
>
> Ok, I have put up a web page that will track my efforts.
>
> http://apollo.backplane.com/FreeBSDSmp/
Your first patchset contains only i386 code.
What is the timeframe for alpha relative to i386?
Will each i386 code s
On Wed, 21 Jun 2000, Mark Murray wrote:
> > Has anyone given any thought to what it would take to create an
> > open source version of something similar to perforce? ;-)
>
> Clearly you have. :-). We await your submissions with baited breath...
I have mixed feelings about that. The Perfo
At 5:00 PM -0400 2000/6/21, Dan Papasian wrote:
> Eivind Elkund was talking about doing something like
> this. He had a pretty nice document about it,
> too. If I recall, the name was "OVCS: Open Version Control System"
Hmm. So far, Google hasn't been particularly useful in trying
At 11:09 PM +0200 2000/6/21, Mark Murray wrote:
>> Has anyone given any thought to what it would take to create an
>> open source version of something similar to perforce? ;-)
>
> Clearly you have. :-). We await your submissions with baited breath...
If you're waiting for me on t
> Has anyone given any thought to what it would take to create an
> open source version of something similar to perforce? ;-)
Clearly you have. :-). We await your submissions with baited breath...
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send m
Eivind Elkund was talking about doing something like
this. He had a pretty nice document about it,
too. If I recall, the name was "OVCS: Open Version Control System"
Perhaps someone could fill in the blanks? I couldn't
find the document at the address I thought it was kept,
http://yes.no/perha
At 9:34 PM +0200 2000/6/21, Soren Schmidt wrote:
> Using a non opensource commercial version control system is just
> to ask for bad carma, extended murphy fields and whatnot in an
> opensource volounteer project...
Has anyone given any thought to what it would take to create an
open
It seems Warner Losh wrote:
> In message <12213.961613148@localhost> "Jordan K. Hubbard" writes:
> : Everyone talks about using bitkeeper but none of the people who
> : recommend it have ever actually tried to use it for anything.
> : Before such recommendations will bear weight, this needs to
> :
In message <12213.961613148@localhost> "Jordan K. Hubbard" writes:
: Everyone talks about using bitkeeper but none of the people who
: recommend it have ever actually tried to use it for anything.
: Before such recommendations will bear weight, this needs to
: change. :)
In that case, I'd recomme
Everyone talks about using bitkeeper but none of the people who
recommend it have ever actually tried to use it for anything.
Before such recommendations will bear weight, this needs to
change. :)
- Jordan
>
> [EMAIL PROTECTED] said:
> :- "CVS branches suck" is the reason I belive.
>
> Bitke
On Tuesday, 20 June 2000 at 11:16:24 +0200, Martin Cracauer wrote:
> In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote:
>>
>> Am I the only person who miss a brief document which tells what
>> the outcome of the meeting was ?
>
> Who was there, anyway?
>From my trip report. This can hardly be conf
On Tuesday, 20 June 2000 at 12:57:41 -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>> I think core has approved in principle, and several core members
>> were present at the meeting (at least peter, dg, gibbs, dfr), that
>> being said, I think we need to s
On Tuesday, 20 June 2000 at 9:41:57 +0200, Poul-Henning Kamp wrote:
>
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?
I'm writing up a detailed trip report for my company. I can't see why
I shouldn't forward it to the SMP list as well, but I
[EMAIL PROTECTED] said:
:- "CVS branches suck" is the reason I belive.
Bitkeeper?
--
Robert Withrow -- (+1 978 288 8256)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
CAM is not a valid example. It only touched the disk subsystem.
Merging back changes in blocks might not be possible. As Matthew
mentioned, Chuck's experience should be taken for a fact.
And bounding the amount of breakage is almost impossible without
squeezing the people doing the SMP work rea
More over, unlike other big project like CAM, this baby is going to
touch the gut of the OS.
It might be possible however for individual projects to move into a
separate branch.
Nick
> >What about doing the changes on a branch with the understanding that
> >the branch will *replace* HEAD when
On Tue, Jun 20, 2000 at 09:41:57AM +0200, Poul-Henning Kamp wrote:
>
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?
I'm at USENIX right now, so I'm a bit strapped for time to work on this.
Still, I plan to email a brief summary of the meeting
Warner Losh writes:
> In message <[EMAIL PROTECTED]> Jason Evans writes:
> : Summary: -current will be destabilized for an extended period (on the order
> : of months). A tag (not a branch) will be laid down before the initial
> : checkin, and non-developers should either stick closely to that ta
> >
> > What about doing the changes on a branch with the understanding that
> > the branch will *replace* HEAD when it stabilises ?
> >
> > This sounds odd at first glance, but it means that others are forced
> > to MFC into the smp branch - if they don't they lose.
> >
> > Anybody that's no
Although I would not like to put it as strongly as Warner does, I would
like to ask how the decision makers expect the rest of the project to
progress (the other 30 or so kernel committers) in a reasonable, not
too time consuming way.
Will there be a general mechanism for making patchsets agains
>
> What about doing the changes on a branch with the understanding that
> the branch will *replace* HEAD when it stabilises ?
>
> This sounds odd at first glance, but it means that others are forced
> to MFC into the smp branch - if they don't they lose.
>
> Anybody that's not confident to b
In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
>In article [EMAIL PROTECTED]> you write:
>>
>>Am I the only person who miss a brief document which tells what
>>the outcome of the meeting was ?
>
>I believe that Jason Evans already sent a message summarizing the
>meeting, and Matt Dillon's
In message <[EMAIL PROTECTED]>, Brian Somers writes:
>What about doing the changes on a branch with the understanding that
>the branch will *replace* HEAD when it stabilises ?
"CVS branches suck" is the reason I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In article [EMAIL PROTECTED]> you write:
>
>Am I the only person who miss a brief document which tells what
>the outcome of the meeting was ?
I believe that Jason Evans already sent a message summarizing the
meeting, and Matt Dillon's webpage gives a pretty good summary of
the work too (at http:
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
This sounds odd at first glance, but it means that others are forced
to MFC into the smp branch - if they don't they lose.
Anybody that's not confident to be able to merge i
In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: The problem is that the changes are simply too extensive to be able
: be able to split them off then merge them back into 5.x N months later.
: Creating another branch will tripple the workload on anyone doing
: merge work.
On Tue, Jun 20, 2000 at 08:49:27PM +0200, Poul-Henning Kamp wrote:
> So: No I don't like -current being toast anymore than you do, but
> I don't think there is a viable alternative.
Not even a seperate repository, as was done (briefly) for newbus?
Of course, maybe that was done so briefly becau
:: the kernel stabilizes, or expect large doses of pain. This tag will be
:: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:: beforehand.
:
:Thanks for the fair warning. Now don't do it. Has core approved
:this? I don't think so, I've seen nothign from them about it.
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
>: I think core has approved in principle, and several core members
>: were present at the meeting (at least peter, dg, gibbs, dfr), that
>: being said, I think we need to see some more co
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete info before
: we pull the lever, just so we know
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <[EMAIL PROTECTED]> Jason Evans writes:
>: Summary: -current will be destabilized for an extended period (on the order
>: of months). A tag (not a branch) will be laid down before the initial
>: checkin, and non-developers should eit
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: Am I the only person who miss a brief document which tells what
: the outcome of the meeting was ?
:
: Can we get to see the slides ?
:
: Audio ?
:
: Video ?
I know that I'd love to see this. Steve Passe also is interested.
Warner
In message <[EMAIL PROTECTED]> Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months). A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either stick closely to that tag until
: the kernel stabili
Martin Cracauer wrote:
>
> In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote:
> >
> > Am I the only person who miss a brief document which tells what
> > the outcome of the meeting was ?
>
> Who was there, anyway?
Yeah, those of us who couldn't make it are kinda (to say the least)
interested in w
In <[EMAIL PROTECTED]>, Poul-Henning Kamp wrote:
>
> Am I the only person who miss a brief document which tells what
> the outcome of the meeting was ?
Who was there, anyway?
Martin
--
%
Martin Cracauer <[EMAIL PROTECTED]> http:/
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Can we get to see the slides ?
Audio ?
Video ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-taho
:On this page, you say:
:
: The algorithms described on this page are essentially the BSDI algorithms
: plus accomodations we disussed at the Yahoo SMP meeting. However, I did
: not do a direct port. I did a from-scratch rewrite because, simply put,
: it was easier for me. The variables are na
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
> Ok, I have put up a web page that will track my efforts.
>
> http://apollo.backplane.com/FreeBSDSmp/
On this page, you say:
The algorithms described on this page are essentially the BSDI algorithms
plus accomodation
:Summary: -current will be destabilized for an extended period (on the order
:of months). A tag (not a branch) will be laid down before the initial
:checkin, and non-developers should either stick closely to that tag until
:the kernel stabilizes, or expect large doses of pain. This tag will be
:
> On a totally non-technical, but somewhat related note, can anyone
> give me any kind of idea how often relatively "large scale" changes
> like this typically occur with FreeBSD?
IIRC, this is the biggest operation of its sort since 2.1.
Can't comment on anything before then, I wasn't a
At 11:53 AM -0700 2000/6/19, Jason Evans wrote:
> Last week, approximately 20 BSD developers got together and discussed how
> to move FreeBSD's SMP support to the next level. Our effort will be
> largely based on the work that has been done in BSD/OS, which should make
> things go much more
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel stabilizes, or expect large doses of pain. This tag will be
laid
53 matches
Mail list logo
