Nicholas Bastin wrote:
> Not completely. More like -0 at the moment. We need a better system,
> but I think we shouldn't just pick a system because it's the one the
> PEP writer preferred - there should be some sort of effort to test a
> few systems (including bug trackers).
But that's how the P
On Mon, 2005-08-15 at 12:27 -0400, Nicholas Bastin wrote:
> On 8/8/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Nicholas Bastin wrote:
> > > It's a mature product. I would hope that that would count for
> > > something.
> >
> > Sure. But so is subversion.
>
> I will then assume that you
On 8/8/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nicholas Bastin wrote:
> > It's a mature product. I would hope that that would count for
> > something.
>
> Sure. But so is subversion.
I will then assume that you and I have different ideas of what 'mature' means.
> So I should then rem
On Sunday 07 August 2005 15:33, Martin v. Löwis wrote:
> Ah, ok. That's true. It doesn't mean you can't do proper merging
> with subversion - it only means that it is harder, as you need to
> figure out the revision range that you want to merge.
>
> If this is too painful, you can probably use subv
[Guido van Rossum wrote]
> Also, P4 has *no* command to tell you which
> files you've created without adding them to the repository yet -- so
> the most frequent build breakage is caused by missing new files.
This one is a frequent complaint from CVS-heads here at ActiveState.
I have a p4 wrapper
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I'm intrigued by Linus Torvald's preference for extremely distributed
> source control, but I have no experience and it seems a bit, um,
> experimental.
"git", which is Linus' home-grown replacement for BitKeeper, quickly attracted
a development com
On 8/10/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> in contrast, Perforce just runs and runs and runs. the clients always
> do what you tell them. and server maintenance is trivial; just make sure
> that the server starts when the host computer boots, and if you have
> enough disk, just leave
Nicholas Bastin wrote:
> It's a mature product. I would hope that that would count for
> something. I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system. I
> know I'm not the only person with this experience.
compared to Pe
On Mon, 2005-08-08 at 19:29, Tim Peters wrote:
> > Currently with svn you have to manually specify those 9 to be sure to not
> > include the remaining one. With p4 you just say to check-in the whole tree
> > and then remove that one from the list give you in your editor with entering
> > the check
Trent Mick wrote:
> One feature I like in Perforce (which Subversion doesn't have) is the
> ability to have pending changesets.
That sounds useful.
> Currently with svn you have to manually
> specify those 9 to be sure to not include the remaining one. With p4 you
> just say to check-in the whole
> "Donovan" == Donovan Baarda <[EMAIL PROTECTED]> writes:
Donovan> It all comes down to how painless branch/merge is. Many
Donovan> esoteric "features" of version control systems feel like
Donovan> they are there to workaround the absence of proper
Donovan> branch/merge histori
On Mon, 2005-08-08 at 17:51, Trent Mick wrote:
[...]
> [Donovan Baarda wrote]
> > On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
[...]
> You want to do checkins of code in a consisten state. Some large changes
> take a couple of days to write. During which one may have to do a couple
> minor things
Who made me the Perforce-bitch? Here I am screaming "Subversion!
Subversion!" and y'all think I just using that as cover for a p4 lover
affair. :)
[Donovan Baarda wrote]
> On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
> > One feature I like in Perforce (which Subversion doesn't have) is the
> >
[Tim Peters wrote]
> [Trent Mick]
> > ...
> > There are other little things, like not being able to trim the check-in
> > filelist when editing the check-in message. For example, say you have
> > 10 files checked out scattered around the Python source tree and you
> > want to check 9 of those in.
On Mon, 2005-08-08 at 15:49, Trent Mick wrote:
> One feature I like in Perforce (which Subversion doesn't have) is the
> ability to have pending changesets. A changeset is, as with subversion,
> something you check-in atomically. Pending changesets in Perforce allow
> you to (1) group related files
[Trent Mick]
> ...
> There are other little things, like not being able to trim the check-in
> filelist when editing the check-in message. For example, say you have
> 10 files checked out scattered around the Python source tree and you
> want to check 9 of those in.
This seems dubious, since you'
One feature I like in Perforce (which Subversion doesn't have) is the
ability to have pending changesets. A changeset is, as with subversion,
something you check-in atomically. Pending changesets in Perforce allow
you to (1) group related files in a source tree where you might be
working on multipl
Trent Mick wrote:
>>No. The PEP is only about Subversion. Why should we be looking at Per
>>Force? Only because Python is Open Source?
>
>
> Perforce offers free licensing to open source projects.
Ok, so I now got "it's mature", and "it would be without charges".
Given that it is now running aga
On Mon, Aug 08, 2005, Trent Mick wrote:
>Martin:
>>
>> No. The PEP is only about Subversion. Why should we be looking at Per
>> Force? Only because Python is Open Source?
>
> Perforce offers free licensing to open source projects.
So did BitKeeper. Linux got bitten by that. We'd need a strong
[Aahz wrote]
> On Sun, Aug 07, 2005, Barry Warsaw wrote:
> >
> > We'd also have to teach the current crop of developers how to use the
> > client tools effectively. I think it's fairly simple to teach a CVS
> > user how to use Subversion, but have no idea if translating CVS
> > experience to Perfo
> > Since Python is Open Source are you looking at Per Force which you can
> > use for free and seems to be a happy medium between something like CVS
> > and something horrific like Clear Case?
>
> No. The PEP is only about Subversion. Why should we be looking at Per
> Force? Only because Python i
On Sun, Aug 07, 2005, Barry Warsaw wrote:
>
> We'd also have to teach the current crop of developers how to use the
> client tools effectively. I think it's fairly simple to teach a CVS
> user how to use Subversion, but have no idea if translating CVS
> experience to Perforce is as straightforward
Barry Warsaw <[EMAIL PROTECTED]> writes:
> Unfortunately, I don't think "we" (meaning specifically the collective
> python.org admins) have much if any operational experience with
> Perforce.
Also (from someone who is on the fringes of the pydotorg admin set): I
don't know that much about subvers
On Sun, Aug 07, 2005 at 11:51:49PM -0400, Barry Warsaw wrote:
> Has anyone experienced svn corruptions with the fsfs backend? I
> haven't, across quite a few repositories.
I haven't. But I must admit that the repositories I'm working with
aren't big. The bigest is at svn.colorstudy.com (I am w
Nicholas Bastin wrote:
> It's a mature product. I would hope that that would count for
> something.
Sure. But so is subversion.
> I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system.
I had the last corrupted repository with
On Sun, 2005-08-07 at 21:52, Nicholas Bastin wrote:
> I've had enough corrupted subversion repositories that I'm
> not crazy about the thought of using it in a production system. I
> know I'm not the only person with this experience. Sure, you can keep
> backups, and not really lose any work, bu
On 8/4/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nicholas Bastin wrote:
> > Perforce is a commercial product, but it can be had for free for
> > verified Open Source projects, which Python shouldn't have any problem
> > with. There are other problems, like you have to renew the agreement
Martin v. Löwis wrote:
> Donovan Baarda wrote:
>>What this means is SVN has no way of automatically identifying the
>>common version.
> If this is too painful, you can probably use subversion to store
> the relevant information. For example, you could define a custom
> property on the directory
Donovan Baarda wrote:
> What this means is SVN has no way of automatically identifying the
> common version.
Ah, ok. That's true. It doesn't mean you can't do proper merging
with subversion - it only means that it is harder, as you need to
figure out the revision range that you want to merge.
If
Martin v. Löwis wrote:
> Donovan Baarda wrote:
>
>>Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
>>properly. All the other cool stuff like renames etc is kinda undone by
>>that. For a definition of properly, see;
>>
>>http://prcs.sourceforge.net/merge.html
>
>
> Can you ple
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>BTW, in one of your replies I read that you had a problem with
>>how cvs2svn handles trunk, branches and tags. In reality, this
>>is no problem at all, since Subversion is very good at handling
>>moves within the repository: you can easily change t
Donovan Baarda wrote:
> Yeah. IMHO the sadest thing about SVN is it doesn't do branch/merge
> properly. All the other cool stuff like renames etc is kinda undone by
> that. For a definition of properly, see;
>
> http://prcs.sourceforge.net/merge.html
Can you please elaborate? I read the page, and
Fernando Perez wrote:
> I know Joe was in contact with the SVN devs to work on this, so perhaps he's
> using a patched version of cvs2svn, I simply don't know. But I mention it in
> case it proves useful to the python.org conversion.
Thanks for the pointer. It turns out that I could resolve all m
Jeff Rush wrote:
> BTW, re SSH access on python.org, using Apache's SSL support re https would
> provide as good of security without the risk of giving out shell accounts.
> SSL would encrypt the link and require a password or permit cert auth
> instead, same as SSH. Cert admin needn't be hard
Phillip J. Eby wrote:
> Yeah, in my use of SVN I find that this is more theoretical than actual
> for certain use cases. You can see the history of a file including the
> history of any file it was copied from. However, if you want to try to
> look at the whole layout, you can't easily get to the
M.-A. Lemburg wrote:
> BTW, in one of your replies I read that you had a problem with
> how cvs2svn handles trunk, branches and tags. In reality, this
> is no problem at all, since Subversion is very good at handling
> moves within the repository: you can easily change the repository
> layout after
Phillip J. Eby wrote:
> At 08:28 PM 8/4/2005 +0200, M.-A. Lemburg wrote:
>
>> BTW, in one of your replies I read that you had a problem with
>> how cvs2svn handles trunk, branches and tags. In reality, this
>> is no problem at all, since Subversion is very good at handling
>> moves within the repo
At 08:28 PM 8/4/2005 +0200, M.-A. Lemburg wrote:
>BTW, in one of your replies I read that you had a problem with
>how cvs2svn handles trunk, branches and tags. In reality, this
>is no problem at all, since Subversion is very good at handling
>moves within the repository: you can easily change the r
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I guess this was a misunderstanding on my part: VA doesn't offer
>>their commercial solution in an ASP-like way. Their product,
>>called SourceForge Enterprise, is a J2EE application which we'd
>>have to install and run. They do mention Subversion
M.-A. Lemburg wrote:
> I guess this was a misunderstanding on my part: VA doesn't offer
> their commercial solution in an ASP-like way. Their product,
> called SourceForge Enterprise, is a J2EE application which we'd
> have to install and run. They do mention Subversion as being
> supported by the
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>>I haven't received any offers to make a qualified statement. I only
>>>know that I would oppose an approach to ask somebody but our
>>>volunteers to do it for free, and I also know that I don't want to
>>>spend my time researching commercial alter
Nicholas Bastin wrote:
>>No. The PEP is only about Subversion. Why should we be looking at Per
>>Force? Only because Python is Open Source?
>
>
> Perforce is a commercial product, but it can be had for free for
> verified Open Source projects, which Python shouldn't have any problem
> with. Ther
> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> Other non-commercial alternatives are Berlios and Savannah, but
M> I'm not sure whether they'd offer Subversion support.
Savannah doesn't offer great reliability or support, at least to judge
by the frequency with which the GNU E
> "aahz" == aahz <[EMAIL PROTECTED]> writes:
aahz> I'd rather not rely on licensing of a closed-source system;
aahz> one of the points made during the talk was that the Linux
aahz> project had to scramble when they lost their Bitkeeper
aahz> license
Python is unlikely to thro
On Wed, Aug 03, 2005, Nicholas Bastin wrote:
>
> I'd put $20 on the fact that cvs2svn will *not* work out of the box
> for converting the python repository. Just call it a hunch. In any
> case, the Perforce-supplied cvs2p4 should work at least as well.
Maybe. OTOH, I went to a CVS->SVN talk tod
On Wednesday 03 August 2005 15:01, M.-A. Lemburg wrote:
> Other non-commercial alternatives are Berlios and Savannah, but
> I'm not sure whether they'd offer Subversion support.
Berlios does offer Subversion; the docutils project is using the Berlios
Subversion and SourceForge for everything el
M.-A. Lemburg wrote:
>>I haven't received any offers to make a qualified statement. I only
>>know that I would oppose an approach to ask somebody but our
>>volunteers to do it for free, and I also know that I don't want to
>>spend my time researching commercial alternatives (although I
>>wouldn't m
On 8/2/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> George V. Neville-Neil wrote:
> > Since Python is Open Source are you looking at Per Force which you can
> > use for free and seems to be a happy medium between something like CVS
> > and something horrific like Clear Case?
>
> No. The PEP
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>True, but if we never ask, we'll never know :-)
>>
>>My question was: Would asking a professional hosting company
>>be a reasonable approach ?
>
> It would be an option, yes, of course. It's not an approach that
> *I* would be willing to implement
[Donovan Baarda]
> It is true that some well designed/developed software becomes reliable
> very quicky. However, it still takes heavy use over time to prove that.
There is wisdom in your say! :-)
--
François Pinard http://pinard.progiciels-bpi.ca
_
On Tue, 2005-08-02 at 09:06, François Pinard wrote:
> [Raymond Hettinger]
>
> > >http://www.venge.net/monotone/
>
> > The current release is 0.21 which suggests that it is not ready for
> > primetime.
>
> It suggests it, yes, and to me as well. On the other hand, there is
> a common prejudi
François Pinard wrote:
> So, it might be worth at least a quick look? :-)
Certainly not my look - although I'm willing to integrate
anything that people contribute into the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
M.-A. Lemburg wrote:
> True, but if we never ask, we'll never know :-)
>
> My question was: Would asking a professional hosting company
> be a reasonable approach ?
It would be an option, yes, of course. It's not an approach that
*I* would be willing to implement, though.
>>From the answers, I ta
[Raymond Hettinger]
> >http://www.venge.net/monotone/
> The current release is 0.21 which suggests that it is not ready for
> primetime.
It suggests it, yes, and to me as well. On the other hand, there is
a common prejudice that something requires many releases, or frequent
releases, to be
[François Pinard]
> While some say Subversion is the most reasonable avenue nowadays,
others
> them told me they found something more appealing than Subversion:
>
>http://www.venge.net/monotone/
The current release is 0.21 which suggests that it is not ready for
primetime.
Raymond
[Martin von Löwis]
> The PEP is only about Subversion. I think anything but Subversion is
> ruled out because:
> - there is no offer to host that anywhere (for subversion, there is
> already svn.python.org)
> - there is no support for converting a CVS repository (for subversion,
> there is cvs2
Donovan Baarda <[EMAIL PROTECTED]> writes:
> This is why I don't bother migrating any existing CVS projects to SVN;
> the benefits don't yet outweigh the pain of migrating.
I think they do. I was on dialup for a while, and would have _loved_
Python to be using SVN then -- and given how long diff
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
> > The PSF does have a reasonable budget, so why not use it to
> > maintain the infrastructure needed for Python development and
> > let a company do the administration of the needed servers and
> > the importing of the CSV and tracker items into t
George V. Neville-Neil wrote:
> Since Python is Open Source are you looking at Per Force which you can
> use for free and seems to be a happy medium between something like CVS
> and something horrific like Clear Case?
No. The PEP is only about Subversion. Why should we be looking at Per
Force? Onl
At Mon, 01 Aug 2005 10:52:03 -0700,
Donovan Baarda wrote:
>
> On Sun, 2005-07-31 at 23:54, Stephen J. Turnbull wrote:
> > > "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes:
> >
> > BAW> So are you saying that moving to svn will let us do more long
> > BAW> lived branches? Yay!
> >
> "Donovan" == Donovan Baarda <[EMAIL PROTECTED]> writes:
Donovan> Yeah. IMHO the sadest thing about SVN is it doesn't do
Donovan> branch/merge properly. All the other cool stuff like
Donovan> renames etc is kinda undone by that. [...] This is why
Donovan> I don't bother migr
On Thursday 28 July 2005 13:00, Martin v. Löwis wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS,
I'm +1 on this, assuming we use the fsfs backend, and not the berkeley
DB one. I'm -1 if we're using the bdb backend (I've had nothing but
pain from it).
> CVS ha
On Sun, 2005-07-31 at 23:54, Stephen J. Turnbull wrote:
> > "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes:
>
> BAW> So are you saying that moving to svn will let us do more long
> BAW> lived branches? Yay!
>
> Yes, but you still have to be disciplined about it. svn is not much
>
> "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes:
BAW> So are you saying that moving to svn will let us do more long
BAW> lived branches? Yay!
Yes, but you still have to be disciplined about it. svn is not much
better than cvs about detecting and ignoring spurious conflicts due to
M.-A. Lemburg wrote:
> The PSF does have a reasonable budget, so why not use it to
> maintain the infrastructure needed for Python development and
> let a company do the administration of the needed servers and
> the importing of the CSV and tracker items into their
> systems ?
In principle,
Barry Warsaw wrote:
> On Fri, 2005-07-29 at 16:59, "Martin v. Löwis" wrote:
>
>
>>Perhaps. Somebody would need to research the precise migration
>>procedure. I once tried to move the Python CVS to Sunsite
>>(or its successors), and gave up after half a year of getting
>>nowhere; I'm personally no
Barry Warsaw wrote:
> Now's the time I pipe in to remind everyone that Atlassian has offered
> free (as in beer) versions of Jira and Confluence for the Python project
> (actually any open source project). If you haven't used these, they're
> definitely worth a look. Jira is the issue tracker, Co
At 06:39 PM 7/29/2005 -0400, Barry Warsaw wrote:
>But that would still require us to create accounts for every committer,
>right?
No. Just one account. You can have more than one key listed in
authorized_keys, using svnserve --tunnel-user and sshd will select the
right command based on the pub
On Fri, 2005-07-29 at 18:12, Leif Hedstrom wrote:
> Barry Warsaw wrote:
>
> >Public/private keys would be better, and if anybody knows how to set up
> >a Subversion server to use these without having to create accounts for
> >everyone, I think we (the pythong.org admins) would love your help.
>
On Fri, 2005-07-29 at 16:59, "Martin v. Löwis" wrote:
> Perhaps. Somebody would need to research the precise migration
> procedure. I once tried to move the Python CVS to Sunsite
> (or its successors), and gave up after half a year of getting
> nowhere; I'm personally not keen on repeating such an
On Fri, 2005-07-29 at 17:21, "Martin v. Löwis" wrote:
> Doesn't this give issues as *every* file the starts out renamed? e.g.
> what if you want "revision 100 of project/trunk/foo", but, at revision
> 100, it really was trunk/project/foo?
I think it only matters if you use urls. I working direct
At 05:54 PM 7/29/2005 -0400, Barry Warsaw wrote:
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.
From the svnserve man page:
-t,
On Fri, 2005-07-29 at 00:50, Christopher Petrilli wrote:
> Another thing to look at would be Trac, which we are in the process of
> moving to from the horrendous nightmare of Bugzilla. It's integration
> with SVN as well as Wiki is quite amazing.
Now's the time I pipe in to remind everyone that
Barry Warsaw wrote:
>>That (sort of) *is* plain text passwords. Somebody who took over
>>svn.python.org can get the password. In public-key or digest
>>authentication, this won't be possible.
>
>
> Actually, the passwords are still hashed in the file, so they wouldn't
> be able to extract the pla
On Fri, 2005-07-29 at 17:32, "Martin v. Löwis" wrote:
> > Was this with the file-system back end? What is your current system?
>
> Yes, and it is a 3 GHz dual processor (although I don't think it uses
> two processors) with 1GB RAM (I believe RAM size matters a lot for
> this process; the older
Barry Warsaw wrote:
> I disagree. By reserving password generation to the pydotorg admins, we
> can better insure the passwords are more robust against dictionary
> attacks. See my previous message. I actually /don't/ want individuals
> to be able to set their own passwords. In practice, you on
On Fri, 2005-07-29 at 00:35, "Martin v. Löwis" wrote:
> It's also a convenience issue, and has social aspects. For example,
> firstname.lastname does not work quite well for me, either
> (martin.v.loewis or martin.von.loewis would work better; likewise
> guido.van.rossum?), other users prefer not
On Fri, 2005-07-29 at 17:19, "Martin v. Löwis" wrote:
> I believe this alone either won't work or won't be good enough (not
> sure which one): If you have /bin/false as login shell, and still
> manage to invoke /usr/bin/svnserve remotely, you can likely also
> invoke /usr/bin/cat /etc/passwd remot
Barry Warsaw wrote:
>
>Public/private keys would be better, and if anybody knows how to set up
>a Subversion server to use these without having to create accounts for
>everyone, I think we (the pythong.org admins) would love your help.
>
>
I'll play around with it some this weekend, see what's
"Martin v. Löwis" wrote:
> Fernando Perez wrote:
>> For ipython, which recently went through cvs2svn, I found that moving over
>> to a
>> project/trunk structure was a few minutes worth of work. Since svn has
>> moving commands, it was just a matter of making the extra project/ directory
>> and
>
On Fri, 2005-07-29 at 00:44, "Martin v. Löwis" wrote:
> - assignment of passwords. This I don't like about the current
> pydotorg setup - there should be a way to chose your own password;
> perhaps without involving an administrator.
> I could imagine a web form for password change, and admi
On Fri, 2005-07-29 at 01:00, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > We won't use plain text, but we may (or, we currently do) use basic auth
> > over ssl. The security then is in the passwords, so we have to make
> > sure they're generated securely.
>
> That (sort of) *is* plain text
Jim Fulton wrote:
>> Dunno. For the Python CVS (which translates into some 40,000 revisions),
>> on the machine which I was originally using (1GHz Pentium), conversion
>> took 7h. On my current workstation, it takes a little over an hour.
>
>
> Was this with the file-system back end? What is you
Michael Hudson wrote:
> Would it work/how much risk would it be to create accounts with shell
> /bin/false?
It seems that the pydotorg admins are worried about such a prospect.
I believe this alone either won't work or won't be good enough (not
sure which one): If you have /bin/false as login she
Fernando Perez wrote:
> For ipython, which recently went through cvs2svn, I found that moving over to
> a
> project/trunk structure was a few minutes worth of work. Since svn has moving
> commands, it was just a matter of making the extra project/ directory and
> moving things one level down the
Martin v. Löwis wrote:
> Jim Fulton wrote:
>
>>I did convert projects individually. I told cvs2svn to just create dump
>>files. I then used svnload to load the dump files myself so that
>>I could make each project a top-level directory with it's own
>>trunk, branches and tags.
>>
>>I'd be happy
Martin v. Löwis wrote:
> Jim Fulton wrote:
>
>> I don't expect that this would be an issue for Python.
>
>
> Right.
>
>
>>2. I initially tried to conver our entire repository, including all
>> branches. This would have taken days. I finally decided to just
>> convert our trunk, which t
Jim Fulton wrote:
> I did convert projects individually. I told cvs2svn to just create dump
> files. I then used svnload to load the dump files myself so that
> I could make each project a top-level directory with it's own
> trunk, branches and tags.
>
> I'd be happy to share my scrips, although
Jim Fulton wrote:
>I don't expect that this would be an issue for Python.
Right.
> 2. I initially tried to conver our entire repository, including all
>branches. This would have taken days. I finally decided to just
>convert our trunk, which took several hours. The main time
>s
M.-A. Lemburg wrote:
>>and on python.org instead of sf.net. To facilitate discussion,
>>I have drafted a PEP describing the rationale for doing so, and
>>the technical procedure to be performed.
>
>
> Not sure about the move to svn.python.org. This would
> bind additional developer resources for
On Friday 29 July 2005 09:17, Jim Fulton wrote:
> 1. We were making extensive use of symbolic links to share packages
> among various Zope projects. This requires special care and
> was the main reason I wrote my own scrips.
>
> I don't expect that this would be an issue for Pytho
Martin v. Löwis wrote:
> So do you use project/trunk or trunk/project? If the former, I would
> need to get instructions on how to do the conversion from CVS.
project/trunk/
On Friday 29 July 2005 02:12, Fernando Perez wrote:
> For ipython, which recently went through cvs2svn, I found that mov
On Friday 29 July 2005 06:34, M.-A. Lemburg wrote:
> If SF is such a show-stopper, would it be reasonable to
> look for managed alternatives, such as eg. CollabNet (who
> funded Subversion development) ?
docutils has been using berlios.de for Subversion; that might be a reasonable
option. I'm
Martin v. Löwis wrote:
> Tim Peters wrote:
>
>>Ah, before I forget, "single repository" has worked very well for Zope
>>(which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
>>projects):
>>
>>http://svn.zope.org/
>>
>>Long URLs don't really get in the way in practice (rarely a ne
Tim Peters wrote:
> [Jeff Rush]
>
>>The conversion script isn't perfect and does fail on complex CVS
>>arrangements or where there is extensive history to migate. However it
>>appears above that Martin has already tried the script out, with success.
>
>
> I'd still like to hear from Jim, as I d
Tim Peters wrote:
...
> I'm sending this to Jim Fulton because he did the conversion of Zope
> Corp's code base to SVN. Unfortunately, Jim will soon be out of touch
> for several weeks. Jim, do you have time to summarize the high bits
> of the problems you hit? IIRC, you didn't find any conversi
Martin v. Löwis wrote:
> I'd like to see the Python source be stored in Subversion instead
> of CVS,
+1
> and on python.org instead of sf.net. To facilitate discussion,
> I have drafted a PEP describing the rationale for doing so, and
> the technical procedure to be performed.
Not sure about th
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> - Subversion over SSH, using SSH key pairs. This would require
> to give committers accounts on the machine, which currently is
> ruled out by the administration policy of svn.python.org.
Would it work/how much risk would it be to create account
"Martin v. Löwis" wrote:
> Fred L. Drake, Jr. wrote:
>> More interestingly, keeping it in a single repository makes it easier to
>> merge
>> projects, or parts of projects, together, without losing the history. This
>> would be useful when developing packages that may be considered for the
>> sta
Tim Peters wrote:
> Ah, before I forget, "single repository" has worked very well for Zope
> (which includes top-level Zope2, Zope3, ZODB, ZConfig, zdaemon, ...
> projects):
>
> http://svn.zope.org/
>
> Long URLs don't really get in the way in practice (rarely a need to
> type one after initi
1 - 100 of 130 matches
Mail list logo
