On Wed, Sep 13, 2000 at 11:16:47PM -0400, Barrie Slaymaker wrote:
> Adam Turoff wrote:
> > Well, use CVS, not su.
>
> the su was for when not using the pserver, since I'm not sure whether CVS uses
> your UID, or some environment variable to grab your user name when not using
> the pserver.
Oh, t
Adam Turoff wrote:
>
> On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> > Adam Turoff wrote:
> > > > Feedback welcome.
> > >
> > > I noticed that CVS reports this as part of the version logs:
> > >
> > > date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
> >
On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> Adam Turoff wrote:
> > > Feedback welcome.
> >
> > I noticed that CVS reports this as part of the version logs:
> >
> > date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
>
> Yup: not sure how to orchestrate
Adam Turoff wrote:
>
> > Feedback welcome.
>
> I noticed that CVS reports this as part of the version logs:
>
> date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
Yup: not sure how to orchestrate logging in to the server as different usernames,
or su'ing to be different user
On Wed, Sep 13, 2000 at 07:41:01AM -0400, Barrie Slaymaker wrote:
> Some progress. Below is the cvs log from perl.c for the first 800 and some
> changes. There's a few bugs to work out yet (including the one in VCP::Dest::cvs
> that crapped out at change 871, but you get the idea. It's also not
I wrote:
>
> Nick Ing-Simmons wrote:
> >
> >
> > I see no reason why the perforce changes cannot be 'checked in' to CVS
> > one-by-one so that CVS builds its own representation of the change history.
>
> I've got this working now in a program called 'vcp', I need to test
> p4->cvs updates using
* Nick Ing-Simmons ([EMAIL PROTECTED]) [10 Sep 2000 06:38]:
[...]
> This is a feature of perforce that is useful - it can warn you that
> you are about to change a file that someone else is already working
> on.
As can CVS.
cheers,
--
\def\Koschei{Iain Truskett}% http://eh
Nick Ing-Simmons wrote:
>
>
> I see no reason why the perforce changes cannot be 'checked in' to CVS
> one-by-one so that CVS builds its own representation of the change history.
I've got this working now in a program called 'vcp', I need to test
p4->cvs updates using the perl5 repository next
Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>Adam Turoff wrote:
>
>> *: Sarathy tells me that Perforce sucks at maintaining thousands of
>> anonymous checkouts, while CVS doesn't mind at all.
This is a feature of perforce that is useful - it can warn you that
you are about to change a file th
At 05:27 PM 9/8/00 -0400, Chaim Frenkel wrote:
> > "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
>
>AT> that is lost is who actually made any specific update; all changes
>AT> are made by 'cvs-bot' or somesuch.
>
>Is this a programming issue? or something more fundemental.
>
>(is it time and
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes:
AT> that is lost is who actually made any specific update; all changes
AT> are made by 'cvs-bot' or somesuch.
Is this a programming issue? or something more fundemental.
(is it time and effort or a mismatch between perforce and CVS?)
--
Ch
At 11:30 AM 9/8/00 -0400, Bradley M. Kuhn wrote:
>Adam Turoff wrote:
>
> > *: Sarathy tells me that Perforce sucks at maintaining thousands of
> > anonymous checkouts, while CVS doesn't mind at all. This is a perfect
> > reason to use anon CVS vs. Perforce, but does not require that Perforce be
>
At 10:24 AM 9/8/00 -0400, Bennett Todd wrote:
>2000-09-07-19:50:35 Adam Turoff:
> > > Given that it's only available to people who happen to run supported
> > > platforms,
> >
> > OK. That pegged the fud-o-meter. The list of supported platforms
> > listed on http://www.perforce.com/perforce/load
At 10:48 PM 9/7/00 -0600, Nathan Torkington wrote:
>But I am cool to the idea that we should lose good coders to
>potentially bad ideas. Explore those ideas later, get perl6 working
>first.
Unfortunately we're going to lose good coders regardless of what we do. Any
significant decision's going
Adam Turoff wrote:
> *: Sarathy tells me that Perforce sucks at maintaining thousands of
> anonymous checkouts, while CVS doesn't mind at all. This is a perfect
> reason to use anon CVS vs. Perforce, but does not require that Perforce be
> ditched in favor of CVS, only that an anon CVS gateway b
2000-09-07-19:50:35 Adam Turoff:
> > Given that it's only available to people who happen to run supported
> > platforms,
>
> OK. That pegged the fud-o-meter. The list of supported platforms
> listed on http://www.perforce.com/perforce/loadprog.html is hovering
> around fifty, [...]
Sure hope
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> > They have a catchy slogan for it. They call it the
> >
> >test --> code --> design
> >
> > development cycle.
>
> That sounds bad. I've heard about this style. Co
On Thu, 7 Sep 2000, Michael G Schwern wrote:
> Refactoring is simply the automated alteration of code without
> effecting its purpose. A simple example would be reversing the order
> of arguments in a subroutine. A refactoring tool would be able to do
> this for you automatically and in all cod
On Thu, Sep 07, 2000 at 11:14:34PM -0600, Nathan Torkington wrote:
> I view branches in this initial version as highly unlikely to be
> useful. We need to have a trunk before we can have branches.
I was actually speaking of both the initial development and on from
there. You don't need a trunk
Michael G Schwern writes:
> In effect, instead of having one development track, we could have many
> development tracks, each focused on a single feature, or small group
> of features. This should make work easier, because on each track only
> one thing is changing, so its easier to track down ne
Michael G Schwern writes:
> Could we split this off into a working group and mailing list seperate
> from perl6-meta?
Sure. I'm going to set an aggressive schedule for the decision,
though, because this has all the hallmarks of a religious war. Let's
work through the problems now and be forced
On Thu, Sep 07, 2000 at 10:48:57PM -0600, Nathan Torkington wrote:
> Michael G Schwern writes:
> > There's one solution, now that we have a nifty source control stuff.
> > Branch like mad! Feature creep should be discouraged, but if a group
> > wants to go off and work on something which isn't go
On Thu, Sep 07, 2000 at 10:52:18PM -0600, Nathan Torkington wrote:
> Then we can hear informed criticism and perhaps modify the plan if a
> better system is suggested.
Could we split this off into a working group and mailing list seperate
from perl6-meta?
--
Michael G Schwern http://www.p
Adam Turoff writes:
> 3) Those developers prefer Perforce and should not be forced
> to use CVS because non-committers prefer it.
>
> Is there anything more to be said about Perforce vs. CVS that *isn't* FUD?
You make it sound like we've decided on Perforce. Dan, how about you
sk
Michael G Schwern writes:
> There's one solution, now that we have a nifty source control stuff.
> Branch like mad! Feature creep should be discouraged, but if a group
> wants to go off and work on something which isn't going to make it
> into the next release they can branch and play.
That divi
On Thu, Sep 07, 2000 at 10:15:38PM -0600, Nathan Torkington wrote:
> The hard part is probably going to be resisting the urge to add
> features just because they're possible: once we come up with a design,
> we must code the design, and leave new features for later 6.x
> releases. Feature creep c
Michael G Schwern writes:
> That sounds bad. I've heard about this style. Code now, refactor
> later. Its supposed to avoid the need for sweeping architectural
> decisions early in the project, allow you to recover from bad design
> decisions and return flexibilty to old code.
Well, yes, but a
On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> They have a catchy slogan for it. They call it the
>
>test --> code --> design
>
> development cycle.
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for swe
On Thu, Sep 07, 2000 at 05:31:37PM -0400, Bennett Todd wrote:
> 2000-09-07-17:11:50 Dan Sugalski:
> That's certainly possible, but since the reason we're gathered here
> together working on trying to launch perl6 is a collective belief
> that perl5 has become unmaintainable for further development
Bennett Todd wrote:
> So I ask again: do any _other_ projects,
> preferably ones that aren't regarded as procedural failures that
> need re-inventing from scratch, used perforce? Or is perl5, whose
> failure has brought us out today, its one poster project?
I think reports of perl5's death have
Bennett,
Perforce is a better source code control system than the source
alternatives, and certainly better for the task we face than CVS.
You're certainly not forced to use it. You can, if you rather, grab
snapshot archives, rsync from the repository directory, or even grab a copy
of the sou
2000-09-07-17:11:50 Dan Sugalski:
> Perl 5's development issues have nothing to do with the code
> repository -- [...]
That's certainly possible, but since the reason we're gathered here
together working on trying to launch perl6 is a collective belief
that perl5 has become unmaintainable for fu
At 11:49 AM 9/7/00 -0400, Bennett Todd wrote:
>2000-09-06-10:51:35 Dan Sugalski:
> > >Finally, most free software and open source projects have
> > >standardized on CVS. Do we really have a compelling reason to go
> > >against the standard?
> >
> > Perl 5 uses perforce, [...]
>
>I thought one of t
Michael G Schwern wrote:
>
> On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> > I also think this may well be a good place to apply one of the ideas of XP
> > (Extreme Programming, a fairly flexible small-group software design
> > methodology), namely to write test cases *first* in
2000-09-05-10:53:25 Dan Sugalski:
> >I don't think it's a good idea to build Perl6 development
> >infrastructure around non-free software.
>
> I don't think we should make decisions about the software we use
> for development based on political views. The decisions should be
> based on technical
Adam Turoff wrote:
> On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
> > Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> > I would include "available under a free software license" as part of the
> > definition of "genera
Dan Sugalski wrote:
> At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
> >Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> >I would include "available under a free software license" as part of the
> >definition of "general availability".
On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
> Dan Sugalski wrote:
> > The decisions should be based on technical merit and general availability.
>
> I would include "available under a free software license" as part of the
> definition of "general availability".
Bradley, yo
At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > The decisions should be based on technical merit and general availability.
>
>I would include "available under a free software license" as part of the
>definition of "general availability".
You would, but in this case I don
On Wed, 6 Sep 2000, Bradley M. Kuhn wrote:
[...]
> Also, what if people want to learn how the source system works on their own,
> and experiment with it? With only 100-user license, we are pretty tight as
> to who can do that. There are probably more than 100 people on the various
> perl6 maili
Dan Sugalski wrote:
> I don't think we should make decisions about the software we use for
> development based on political views.
While I do have many political views regarding free software, this is an
issue of ethical views. It against my personal ethics to use proprietary
software. Politic
At 09:29 AM 9/4/00 -0400, Bradley M. Kuhn wrote:
>Ask Bjoern Hansen wrote:
>
> > the perl-qa people have some code they need to manage in a repository of
> > some kind. For now I have directed them to SourceForge, but I have a 100
> > users license for perforce I got for perl, so if we can get a q
> "Bradley" == Bradley M Kuhn <[EMAIL PROTECTED]> writes:
Bradley> On a personal note, I would not be able to participate in
Bradley> Perl6 development if doing so required that I use
Bradley> perforce, because I have personal ethical beliefs that
Bradley> prohibit me from usin
Ask Bjoern Hansen wrote:
> the perl-qa people have some code they need to manage in a repository of
> some kind. For now I have directed them to SourceForge, but I have a 100
> users license for perforce I got for perl, so if we can get a quick
> consensus that we might want to make a perl6 code
On Sun, Sep 03, 2000 at 09:22:55PM -0600, Nathan Torkington wrote:
> Simon Cozens is working on a perforce replacement, with some features
> that the pumpkings of perl5 have asked for. If his gets working, I'd
> love to see it integrated into SourceForge.
Its not entirely clear if you're advocat
On Sun, Sep 03, 2000 at 09:05:07PM -0700, Russ Allbery wrote:
> I also think this may well be a good place to apply one of the ideas of XP
> (Extreme Programming, a fairly flexible small-group software design
> methodology), namely to write test cases *first* in many cases before
> writing the cod
On Sun, Sep 03, 2000 at 10:09:00PM -0600, Nathan Torkington wrote:
> True. We're still a ways off needing a place to put code
Speak for yourself, laggard. :P
> (a question for those who have done this before: do these source
> code control systems work equally well for the design and test
> d
Russ Allbery writes:
> I also think this may well be a good place to apply one of the ideas of XP
> (Extreme Programming, a fairly flexible small-group software design
> methodology), namely to write test cases *first* in many cases before
> writing the code, and to seriously consider trying to wr
Michael G Schwern writes:
> Its not entirely clear if you're advocating we wait for this Perforce
> replacement before instituting a cannoical Perl 6 repository, or just
> mentioning it.
Mentioning it, and I had been opening discussion on instituting it.
> If its the former, then as a rule of th
Nathan Torkington <[EMAIL PROTECTED]> writes:
> I picture the design process ending with a breakdown into modules, and
> then a codification of the interfaces between the modules. Then we stub
> the modules, get something that passes the compiler. Now we turn to
> implementation, and begin fill
Ask Bjoern Hansen writes:
> the perl-qa people have some code they need to manage in a
> repository of some kind. For now I have directed them to
> SourceForge, but I have a 100 users license for perforce I got for
> perl, so if we can get a quick consensus that we might want to make
> a perl6 cod
51 matches
Mail list logo
