Re: Branching

2008-08-05 Thread jerry gay
On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote: > On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote: >> We also need to think about deprecation cycles. If you deprecate a >> feature in 1 version and then it disappears in the next then the time >> between when my

Re: Branching

2008-08-05 Thread Geoffrey Broadwell
On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote: > We also need to think about deprecation cycles. If you deprecate a > feature in 1 version and then it disappears in the next then the time > between when my code works and when it doesn't is only 6 months. Some > distros provide support

Re: Branching

2008-08-05 Thread chromatic
On Tuesday 05 August 2008 13:19:52 Michael Peters wrote: > If you deprecate a > feature in 1 version and then it disappears in the next then the time > between when my code works and when it doesn't is only 6 months. Some > distros provide support for several years. If they want to support ancien

Re: Branching

2008-08-05 Thread chromatic
On Tuesday 05 August 2008 13:14:27 Geoffrey Broadwell wrote: > > I can see patching the previous release in case of a critical bugfix, but > > if we get in the habit of encouraging users to expect updates of anything > > older than the previous stable release for free, we've doomed the > > project

Re: Branching

2008-08-05 Thread Jesse Vincent
On Aug 5, 2008, at 3:46 PM, Geoffrey Broadwell wrote: On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote: ["branch" feature] This sounds very useful. Is the SVK paradigm changing so that online use is assumed, and offline is a mode to switch to temporarily? No. But that's a common eno

Re: Branching

2008-08-05 Thread Michael Peters
Geoffrey Broadwell wrote: Complete and utter refusal to support users who expect that they can install Parrot 1.0 and get free support from the mailing list or IRC for the next eight to ten years. Half agree. I agree that we should only *directly* support a release for a limited time, thoug

Re: Branching

2008-08-05 Thread Geoffrey Broadwell
On Tue, 2008-08-05 at 12:54 -0700, chromatic wrote: > On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote: > > bugfixes that should be backported to one or more already released > > versions and re-released immediately. > > I can see patching the previous release in case of a critical bugfi

Re: Branching

2008-08-05 Thread chromatic
On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote: > We will definitely need multiple long-lived branches. Just to make > explicit the reasoning: data loss, security, or otherwise critical > bugfixes that should be backported to one or more already released > versions and re-released im

Re: Branching

2008-08-05 Thread Geoffrey Broadwell
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote: > ["branch" feature] This sounds very useful. Is the SVK paradigm changing so that online use is assumed, and offline is a mode to switch to temporarily? I'm used to thinking of SVK in one two ways: 1. As a better SVN client for normal

Re: Branching

2008-08-05 Thread Geoffrey Broadwell
On Tue, 2008-08-05 at 13:20 -0400, Will Coleda wrote: > On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote: > > Gah, no maintenance releases please! See "Mommy, why did it take over five > > years to release a new stable version of Perl 5 with a bugfix I made in > > 2002?" > > Per

Re: Branching

2008-08-05 Thread Will Coleda
On Tue, Aug 5, 2008 at 1:10 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Tuesday 05 August 2008 09:48:22 Will Coleda wrote: > >> Branches that don't rebase from trunk regularly are out of >> touch, yes. If you rebase regularly, then you're basically just a >> patch waiting to be applied. > ... an

Re: Branching

2008-08-05 Thread chromatic
On Tuesday 05 August 2008 09:48:22 Will Coleda wrote: > Branches that don't rebase from trunk regularly are out of > touch, yes. If you rebase regularly, then you're basically just a > patch waiting to be applied. ... and, as time goes by, an ever-larger patch waiting to land on trunk with a big

Re: Branching

2008-08-05 Thread Will Coleda
On Tue, Aug 5, 2008 at 12:16 PM, Andy Lester <[EMAIL PROTECTED]> wrote: > > On Aug 5, 2008, at 11:12 AM, chromatic wrote: > >> Don't use long-lived branches. The smaller the merge in *any* system, the >> easier it is. > > > I agree 100%. If you think your project is so big that you have to have a

Re: Branching

2008-08-05 Thread Andy Lester
On Aug 5, 2008, at 11:12 AM, chromatic wrote: Don't use long-lived branches. The smaller the merge in *any* system, the easier it is. I agree 100%. If you think your project is so big that you have to have a long-lived branch, then it should be broken up into smaller, mergeable miles

Re: Branching

2008-08-05 Thread chromatic
On Tuesday 05 August 2008 07:51:35 Will Coleda wrote: > Using svn as a backing store, how can we more easily work with long > lived branches? > > I've some existing branches which are long lived, and doing the svn > merge either way is extremely slow. > > I know much of our community used svk for

Re: Branching

2008-08-05 Thread Jesse Vincent
On Aug 5, 2008, at 11:50 AM, Reini Urban wrote: 2008/8/5 Will Coleda <[EMAIL PROTECTED]>: So these branch commands actually create branches on the svn repository that's doing the hosting, so they're defacto shared with the community in the obvious location? (presuming you're online and pushing

[Fwd: Re: Branching]

2008-08-05 Thread Kevin Tew
--- Begin Message --- Will Coleda wrote: On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote: Git is really nice for: local branches, This is on par with svk... frequently(daily) rebasing local branches to keep in sync with HEAD, How does this work?

Re: Branching

2008-08-05 Thread Reini Urban
2008/8/5 Will Coleda <[EMAIL PROTECTED]>: > So these branch commands actually create branches on the svn > repository that's doing the hosting, so they're defacto shared with > the community in the obvious location? (presuming you're online and > pushing changes back?) > > That seems to be the best

Re: Branching

2008-08-05 Thread Jesse Vincent
On Aug 5, 2008, at 11:32 AM, Will Coleda wrote: [SVK 2.2] Sounds spiffy. So these branch commands actually create branches on the svn repository that's doing the hosting, so they're defacto shared with the community in the obvious location? (presuming you're online and pushing changes back?

Re: Branching

2008-08-05 Thread Will Coleda
On Tue, Aug 5, 2008 at 11:19 AM, Jesse Vincent <[EMAIL PROTECTED]> wrote: > > On Aug 5, 2008, at 10:51 AM, Will Coleda wrote: > >> Using svn as a backing store, how can we more easily work with long >> lived branches? >> >> I've some existing branches which are long lived, and doing the svn >> merg

Re: Branching

2008-08-05 Thread Jesse Vincent
On Aug 5, 2008, at 10:51 AM, Will Coleda wrote: Using svn as a backing store, how can we more easily work with long lived branches? I've some existing branches which are long lived, and doing the svn merge either way is extremely slow. I know much of our community used svk for a while; I thin

Re: Branching

2008-08-05 Thread Will Coleda
On Tue, Aug 5, 2008 at 11:04 AM, Kevin Tew <[EMAIL PROTECTED]> wrote: > Git is really nice for: >local branches, This is on par with svk... >frequently(daily) rebasing local branches to keep in sync with HEAD, How does this work? What's the pain threshold? >publishing local branches

Re: Branching

2008-08-05 Thread Kevin Tew
Git is really nice for: local branches, frequently(daily) rebasing local branches to keep in sync with HEAD, publishing local branches for others to review, allowing non-committers to make changes and publish those changes publicly Kevin Will Coleda wrote: Using svn as a backi

Re: Branching off the tree

2004-11-05 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Since I'm about to start in on some of the Irrevocable Changes (or > something like that) to the string system with the new > encoding/charset stuff, I tagged CVS and will be working in a branch > (I hope). > If you feel like watching or playing along at h